nplus

Versioning

Mon, 01 Jan 0001 00:00:00 +0000

Versioning#

Since 26.4, the nplus version is independent of the nscale version. All nplus charts — the instance, the environment, the cluster and every component — carry the same nplus version. Which nscale version runs is decided by the values, not by the chart version.

nplus versions#

Channel	Form	Example	Helm
Release	`X.Y.<rev>`	`26.4.1000`, `26.4.1001`	`helm install` / `helm upgrade`
Development	`X.Y.1000-<n>`	`26.4.1000-1`, `26.4.1000-2`	`helm install --devel`

X.Y is the release line. It follows the calendar: 26.4 is the line of 2026. A new line starts when the chart code changes in a way that needs attention on upgrade.
rev counts the releases of a line, starting at 1000. Every published version passed the full test suite.
Development versions are pre-releases of the next release in SemVer terms (26.4.1000-2 < 26.4.1000), so helm install without --devel never picks one up.

Versions before 26.3 followed the nscale Application Layer version (for example 10.2.1002-200). They remain available, but receive no updates. 26.3.200 is exactly the code of beta 200 under the new number: switch to it first, without any change to your deployment, and move on to 26.4 from there.

Quickstart

Mon, 01 Jan 0001 00:00:00 +0000

nplus Quickstart Guide#

The charts are built in a way that they provide minimal functionality without any configuration, using default values.

If you want ingress, you have to configure the domain. Without the domain set, your charts will not have any default way to access them. However, you can still forward traffic to them or configure a NodePort or LoadBalancer manually.
If you want proper TLS, you need a certificate. Without the certificate provided, a self-signed certificate will secure your connection.
If you want specific storage, configure the storage class to use. Without it, you will get the default class for RWO and RWX.

This Quick Start example has nothing configured, so you will get:

Quickstart with Argo CD

Mon, 01 Jan 0001 00:00:00 +0000

This guide extends the Quickstart Guide, so make sure you have completed that before starting with ArgoCD.

Adding ArgoCD#

In order to be able to deploy nplus instances using ArgoCD, you need to add the Chart Repository to Argo:

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
 name: nplus-repo
 namespace: argocd
 labels:
 argocd.argoproj.io/secret-type: repository
stringData:
 type: helm
 url: https://git.42i.org/api/packages/nplus/helm
 password: $NPLUS_TOKEN
 username: $NPLUS_ACCOUNT
EOF

This requires the Environment Variables for the NPLUS_ACCOUNT and NPLUS_TOKEN to be set. Check the Quickstart Guide if you are uncertain

FAQ

Mon, 01 Jan 0001 00:00:00 +0000

Frequently Asked Questions (FAQ)#

How do I add my custom Generic Base App (GBA) to the deployment?#

You can use the application chart to add your GBAs to a deployment. Please follow the instructions in the chart README.

I do not find any of my custom objects (roles, classes, …) from my GBA in the system. Is there an install log file that I can check?#

Yes. You can either check the log of the application job with

nscale versions

Mon, 01 Jan 0001 00:00:00 +0000

nscale versions#

Each file pins the images of every nscale component for one nscale release. The charts default to the latest one (10.2.1001). Stack a file on top of your values to run another release, see Versioning.

nscale	file
10.2.1001	10.2.1001.yaml
10.1.1509	10.1.1509.yaml
10.1.1500	10.1.1500.yaml
10.1.1303	10.1.1303.yaml
10.1.1301	10.1.1301.yaml
10.1.1101	10.1.1101.yaml
10.0.1503	10.0.1503.yaml
10.0.1502	10.0.1502.yaml
10.0.1300	10.0.1300.yaml
10.0.1101	10.0.1101.yaml
10.0.1001	10.0.1001.yaml
9.3.1401	9.3.1401.yaml
9.3.1300	9.3.1300.yaml
9.3.1202	9.3.1202.yaml
9.2.1505	9.2.1505.yaml
9.2.1503	9.2.1503.yaml
9.2.1502	9.2.1502.yaml
9.2.1501	9.2.1501.yaml
9.2.1402	9.2.1402.yaml
9.2.1302	9.2.1302.yaml
9.2.1200	9.2.1200.yaml
9.2.1101	9.2.1101.yaml
9.2.1005	9.2.1005.yaml
9.2	9.2.yaml
9.1.1506	9.1.1506.yaml
9.1.1501	9.1.1501.yaml
9.1.1401	9.1.1401.yaml
9.1.1300	9.1.1300.yaml
9.1.1201	9.1.1201.yaml
9.1.1100	9.1.1100.yaml
9.1.1001	9.1.1001.yaml
9.0.1501	9.0.1501.yaml
9.0.1400	9.0.1400.yaml

Operations

Mon, 01 Jan 0001 00:00:00 +0000

Day 1 Ops: Install, Update, Uninstall#

Install instance sample

To demonstrate, we use the sample-tenant chart we find in the samples directory. The main difference to the default instance chart is, that a domain is set to *.sample.nplus.cloud, so we will be able to log into the web client right away if we redirected this domain correctly.

You can easily adopt the examples to your environment.
```
helm install sample nplus/sample-tenant --version 9.0.1400
```
Rolling update of instance sample to a later monthly release

Release history

Mon, 01 Jan 0001 00:00:00 +0000

Version History#

September 2026, Beta 200#

Removed the JSONL export of the documentation. subscription/ai/jsonl held a copy of the chart and manual documentation for feeding into an LLM, generated by two helper scripts and a helm-docs template. Nobody consumed it, the scripts carried their input and output paths hard coded as devcontainer paths, and bin/build called them with || true - so outside a devcontainer they failed silently and the files quietly went stale. Documentation now lives in the chart READMEs and under docs/ only.

September 2026, Beta 199#

The Component and Instance custom resources no longer carry tenant and provider when they are not set. Both belong to cloud billing and stay empty on premise, but were rendered unconditionally and arrived as null in the resource - which Argo CD reports as a difference on every sync. They are now written only when they carry a value, on component, instance or environment level alike. Confirmed against a customer’s Argo CD manifest, where both fields showed up as null on all eight components and on the instance.
A component deployed on its own now renders its own TLS certificate. Only the umbrella charts (instance, environment, rms) did so, while every component refers to ingress.secret - so a single component without an instance pointed at a secret that nobody created. With ingress.issuer set it renders a Certificate, otherwise a self signed secret, which ingress.createSelfSignedCertificate: false switches off. Inside an instance or an environment nothing changes: the umbrella chart keeps owning the certificate. This was invisible with provider: ingress in clusters running a cert-manager ingress shim, where the Ingress object triggered the certificate; with provider: traefik there is no Ingress to trigger anything, and Traefik answered with its default certificate instead - which looks like a broken TLS setup rather than a missing object. Note that the self signed certificate is regenerated on every render and that several standalone components in one namespace share the secret name.
The component list of the Instance custom resource no longer contains sim. components.sim is not a component but the section for single instance mode, and a non empty map counts as true - so a component that will never exist ended up in components and in expected, where the operator waits for it. Only real on/off switches are listed now; the sub charts of single instance mode keep their own conditions.
The annotations block of a pod template is only written when there is something to annotate. Components without OpenTelemetry injection and without security annotations rendered an empty annotations:, which arrives as null in the cluster and is reported as a difference on every Argo CD sync. The new helper nplus.podAnnotations brings the key along with its content, and takes an own annotation as a second argument for the components that always set one.
Fixed the component and instance templates swallowing their own indentation: component.tpl passed the rendered resource through without nindent, so the first line kept the template indentation. Helm trims that away before applying, which is why it never showed in a cluster, but it made the resource unparseable for anything reading the template output directly - chart unit tests among them.

September 2026, Beta 198#

Values are rendered key by key: what is not set no longer appears in the manifest. The new helper nplus.compact drops empty entries from a values block — null, the empty string, and maps or lists that end up empty — while 0 and false are kept, because those are values rather than omissions. It is applied to resources, initResources, sidecarResources, both security contexts and the Traefik sticky cookie, and is available for any other block that reaches the manifest through toYaml.
Environment variables built from maps (env, global.env, global.environment.env) skip entries without a value — an unset key rendered as value: with nothing behind it, a null in the manifest. An empty string is kept: for an environment variable, “set but empty” differs from “not set”. The values files declare the full shape (requests/limits with cpu/memory), so unset keys arrived as cpu: null — and Helm 4, as used by newer Argo CD versions, reads that as 0, which kept applications permanently out of sync. Empty sections are dropped as well, and a block without any value at all is omitted entirely. Resource kinds beyond cpu and memory (ephemeral-storage, GPU) are preserved.

September 2026, Beta 197#

Added ingress.labels: extra labels for everything the ingress path creates — the Ingress as well as IngressRoute, Middleware, ServersTransport, HTTPRoute and Gateway. Clusters that enforce labels on these objects (a Kyverno policy requiring traefik-scope on every Traefik CR, for example) rejected the whole deployment before; setting the label once on environment or instance level now covers every component and the shared objects.

August 2026, Beta 196#

Fixed the SharePoint cluster ingress, which did not know the traefik provider and aborted the render with unsupported ingress provider: traefik. It now writes an IngressRoute for the cluster service as well.

August 2026, Beta 195#

Added ingress.provider: traefik, publishing a component with native Traefik CRDs instead of a Kubernetes Ingress. Every component renders its own IngressRoute, while the cross cutting middlewares (app-root redirect, request body limit, whitelist) and the ServersTransport are rendered once per instance and referenced by name. A component deployed standalone renders its own copies.
Added per component Traefik options below ingress.traefik: CORS, rate limiting, native sticky cookie settings, body size and timeout overrides, and middlewares to attach middlewares of your own without disabling the nplus routing.
Denied paths (ingress.deny) are answered with 403 by a blocking middleware in this mode, instead of being routed to the void service.
Fixed the app-root redirect middleware: the replacement was written as $${1}, which Traefik expands to a literal dollar sign, so the redirect pointed to https://${1}/... instead of the host. This affected the ingress.backend: traefik variant as well.
Fixed updateStrategy being ignored: the value is documented in nine charts, but only the web chart evaluated it. All deployment charts now honor it, which also makes Recreate available on single node clusters, where a rolling update deadlocks against the pod anti affinity.
Added chart unit tests based on helm-unittest, covering the ingress, traefik and gateway providers. Run them with make test; make beta now runs them before building.
Added the traefik sample comparing both Traefik variants, and documented Traefik in detail in the shared ingress documentation of every chart.

August 2026, Beta 194#

Update nscale to 10.1.1509

March 2026, Beta 193#

Set the http port of the dms api component to 8080
Fixed value resolution for ports, where numbers may arrive as int or int64 depending on whether they come from a values file or the command line

March 2026, Beta 192#

Added ingress.backend switch (nginx or traefik) to the shared ingress template.
Added Traefik middleware manifest generation for app-root redirect, rewrite (inputPath + rewriteTarget), and whitelist.
Added automatic Traefik middleware binding via traefik.ingress.kubernetes.io/router.middlewares.
Remaining non-1:1 topics for Traefik are proxy-read-timeout and custom configuration-snippet based deny rules.
Added the option to add a RAMDrive configuration to the generic Volume list. See the generic example for details.
Update nscale to 10.1.1500

February 2026, Beta 191#

Fixed a bug in the SharePoint Cluster Ingress, where we had a double if enabled preventing it from being generated

February 2026, Beta 190#

Added postgres (official) supprt, see example.
Added Gateway API support replacing ingresses, see example

February 2026, Beta 189#

Implemented ability to override the probes in all charts see the probes sample for demo

February 2026, Release 1.4.1303#

Stable version

February 2026, Beta 187#

Update to nscale 10.1.1303 Some components are on 1400, like Pipeliner.

January 2026, Beta 186#

Update to nscale 10.1.1301
Refactored the dev environment to the new dev container
Refactored the server in the data center

November 2025, Beta 185#

Update to nscale 10.1.1101
Added custom init containers (see sample initcontainers and documentation in README.md for more info)

October 2025, Beta 183#

Update to nscale 10.0.1503

September 2025, Beta 182#

Update to nscale 10.0.1502

August 2025, Beta 181#

No new nscale version available yet (as of 2025-08-05).
Changed the NAPPL probes due to current discussions

July 2025, Beta 180#

Update to nscale 10.0.1300
Added an option to turn off service stickiness in nappl

May 2025, Beta 178/179#

Added revisionHistoryLimit to all charts. You can also set it globally per instance or environment.

May 2025, Beta 177#

Ability to set (and create) a PriorityClass for all components. This was possible for the database and the application layer before. Now you can set it for cmis, ilm, administrator, mon, nappl, nstl, pam, pipeliner, rs, sharepoint, web and webdav. See component README.md for details.
Update to version 10.0.1101
Path types for the default ingress paths in NAPPL were wrong: /engine.properties and /index.html have been changed from Prefix to Exact

April 2025, Beta 176#

NAPPL probes set to official endpoints

April 2025, Beta 175#

Update to nscale 10
Fixed a bug in the Pipeliner ingress

February 2025, Beta 174#

Next to ingress.cookie you can now set ingress.sameSite to strict, lax or none.
Update to 9.3.1401

February 2025, Beta 173#

Set SAPPROXY_CONTEXT_PATH for erpproxy to enable multiple instances on different paths. The Helm value is .this.ingress.contextPath.

February 2025, Release 1.3.1400#

Stable release

January 2025, Beta 171#

values.schema.json were too strict with respect to global and environment settings (AdditionalProperties). Now they are more permissive.
Added erpproxy[a-d] to allow multiple ERP Proxy deployments with different configurations in one nplus instance.
Added ERP-Proxy to DSL for documentation
Updated ERP CMIS version

January 2025, Beta 170#

Added values.schema.json to all charts for validation. Please add, for instance,
```
# yaml-language-server: $schema=/docs/raw/branch/master/charts/instance/values.schema.json
```
to your values file.

January 2025, Beta 169#

Allow the ERP Proxy URL to be fully customizable

January 2025, Beta 168#

Removed the extra certificate from the RMS component

January 2025, Beta 167#

Update to nscale 9.3.1300
Added terminationGracePeriodSeconds to all pods; it can now be set with .terminationGracePeriodSeconds.

December 2024, Beta 166#

The secondary disk is now optional and needs to be enabled with mounts.disk.enabled: true.
The default mount for the HID is now on the secondary disk. If you have HID enabled, this is a breaking change. Make sure you deal with existing HID files.

December 2024, Beta 164#

Separated the buffers and DA for performance reasons in nstl. The buffers are now stored on a new volume disk.
Added /var/crash to nstl, storing potential crash dumps on pTemp.

December 2024, Beta 163#

Update to nscale 9.3.1202
In addition to .this.resources, you can now also set .this.sidecarResources and .this.initResources. However, you should not do so unless you know what you are doing.

December 2024, Beta 162#

Changed resources for the Fluentbit sidecar container

December 2024, Beta 161#

Added startup probes for all components

November 2024, Beta 160#

Added a startup probe for nstl

November 2024, Beta 159#

Added .instance.stage to identify a stage

November 2024, Beta 158#

Added service.name for OpenTelemetry

October 2024, Beta 157#

Latest ERP-Proxy version by Ceyoniq. This also has been renamed to erpproxy to match the erpcmis connector chart naming.
First beta of the ERP-CMIS connector in directory erpcmis
Added the possibility to add annotations to payloads for use with OpenTelemetry
Also see here
Also added hard-coded OpenTelemetry support for convenience
Fixed a bug where the prepper chart waited for post-sync in Argo deployments

October 2024, Beta 156#

nscale ERP Proxy chart now available. There is still a bug in this first image by Ceyoniq, so the chart will not bring up a running system yet. But the values are in, so you can start setting up the instances.

October 2024, Beta 155#

Added the possibility to use ConfigMaps and secrets in the generic mount interface.
Please see the generic example for details

September 2024, Release 1.2.1500#

Update to nscale 9.2.1502

Added value logForwarder.db to set a fully qualified path to the database file, in case you do not want to have it alongside the logs.
Example:

logForwarder:
- name: Accounting
 path: "/opt/ceyoniq/nscale-server/storage-layer/accounting/*.csv"
 db: "/opt/ceyoniq/nscale-server/storage-layer/logsdb/logs.db"

BASEFOLDER value typo corrected in SharePoint. It is now Values.nappl.baseFolder.
The default value for doInitialCrawl was a boolean. It is now a string false, which is correct.

You can now add any extra annotations to services and ingresses. Example:

global:
 ingress:
 annotations:
 nginx.org/proxy-read-timeout: "20s"
 service:
 annotations:
 consul.hashicorp.com/service-sync: "true"

Added .this.ingress.proxyReadTimeout to set this extra annotation on ingress objects
Ports can now be disabled in NetworkPolicies if you use a CNI driver that does not support them. This is especially for the “endPort” attribute, which is currently not supported by Cilium.
Added port 443 to the egress in NetworkPolicies for pods accessing the K8s API
There was a duplicate PodDisruptionBudget. Fixed it.
Fixed a bug with respect to Volume Names / Static Volumes and Storage Classes
Corrected documentation for global.pullSecretOverride (wrong, missing s) and global.pullSecretsOverride (correct)
Fixed a bug where PAM could not communicate with JOBSNAPPL in a HA scenario

August 2024, Release 1.2.1400#

Fixed bugs related to the KubePing protocol in versions < 9.1.

(auto-) certificates and the pitfalls of .this

Mon, 01 Jan 0001 00:00:00 +0000

(auto-) certificates and the pitfalls of .this#

nplus will automatically generate certificates for your ingress. It either uses an issuer like cert-manager or generates a self-signed-certificate.

In your production environment though, you might want to take more control over the certificate generation process and don’t leave it to nplus to automatically take care of it. In that case, you want to switch the automation off.

To do so, you need to understand what is happening internally:

(virtual-) Remote Management Server

Mon, 01 Jan 0001 00:00:00 +0000

(virtual-) Remote Management Server#

The nplus RMS creates a virtual IP Address in your subnet. On this IP, you will find an nscale Remote Management Service and a Layer 4 Proxy, forwarding the ports of the components to the belonging pods.

The result is, that under this VIP, it looks as if there is a real server with a bunch of nscale components installed. So you can use the desktop admin client to connect to it and configure it. Including offline configuration.

chart

Mon, 01 Jan 0001 00:00:00 +0000

chart#

Files#

Download all files of this sample

build.sh#

#!/bin/bash
#
# This sample script builds the example as described. It is also used to build the test environment in our lab,
# so it should be well tested.
#

# Make sure it fails immediately, if anything goes wrong
set -e

# -- ENVironment variables:
# CHARTS: The path to the source code
# DEST: The path to the build destination
# SAMPLE: The directory of the sample
# NAME: The name of the sample, used as the .Release.Name
# KUBE_CONTEXT: The name of the kube context, used to build this sample depending on where you run it against. You might have different Environments such as lab, dev, qa, prod, demo, local, ...

# Check, if we have the source code available
if [ ! -d "$CHARTS" ]; then
 echo "ERROR Building $SAMPLE example: The Charts Sources folder is not set. Please make sure to run this script with the full Source Code available"
 exit 1
fi
if [ ! -d "$DEST" ]; then
 echo "ERROR Building $SAMPLE example: DEST folder not found."
 exit 1
fi
if [ ! -d "$CHARTS/instance" ]; then
 echo "ERROR Building $SAMPLE example: Chart Sources in $CHARTS/instance not found. Are you running this script as a subscriber?"
 exit 1
fi

# Set the Variables
SAMPLE="chart"
NAME="sample-$SAMPLE"

# Output what is happening
echo "Building $NAME"

# Create the manifest
mkdir -p $DEST/instance
helm template --debug \
 --values $SAMPLES/environment/$KUBE_CONTEXT.yaml \
 --values $SAMPLES/chart/resources.yaml \
 $NAME $SAMPLES/chart/tenant > $DEST/instance/$SAMPLE.yaml

# Create the manifest - argo version
mkdir -p $DEST/instance-argo
helm template --debug \
 --values $SAMPLES/environment/$KUBE_CONTEXT.yaml \
 --values $SAMPLES/chart/resources.yaml \
 $NAME-argo $SAMPLES/chart/tenant-argo > $DEST/instance-argo/$SAMPLE-argo.yaml

resources.yaml#

instance:
 web:
 resources:
 requests:
 cpu: "10m"
 memory: "1.5Gi"
 limits:
 cpu: "4000m"
 memory: "4Gi"
 prepper:
 resources:
 requests:
 cpu: "10m"
 memory: "128Mi"
 limits:
 cpu: "1000m"
 memory: "128Mi"
 application:
 resources:
 requests:
 cpu: "10m"
 memory: "1.5Gi"
 limits:
 cpu: "4000m"
 memory: "4Gi"
 nappl:
 resources:
 requests:
 cpu: "10m"
 memory: "1.5Gi"
 limits:
 cpu: "4000m"
 memory: "4Gi"
 nappljobs:
 resources:
 requests:
 cpu: "10m"
 memory: "2Gi"
 limits:
 cpu: "4000m"
 memory: "4Gi"
 administrator:
 resources:
 requests:
 cpu: "2m"
 memory: "512Mi"
 limits:
 cpu: "2000m"
 memory: "2Gi"
 cmis:
 resources:
 requests:
 cpu: "2m"
 memory: "512Mi"
 limits:
 cpu: "2000m"
 memory: "2Gi"
 database:
 resources:
 requests:
 cpu: "2m"
 memory: "256Mi"
 limits:
 cpu: "4000m"
 memory: "8Gi"
 ilm:
 resources:
 requests:
 cpu: "2m"
 memory: "256Mi"
 limits:
 cpu: "2000m"
 memory: "2Gi"
 mon:
 resources:
 requests:
 cpu: "2m"
 memory: "512Mi"
 limits:
 cpu: "2000m"
 memory: "2Gi"
 nstl:
 resources:
 requests:
 cpu: "5m"
 memory: "128Mi"
 limits:
 cpu: "2000m"
 memory: "1Gi"
 nstla:
 resources:
 requests:
 cpu: "5m"
 memory: "128Mi"
 limits:
 cpu: "2000m"
 memory: "1Gi"
 nstlb:
 resources:
 requests:
 cpu: "5m"
 memory: "128Mi"
 limits:
 cpu: "2000m"
 memory: "1Gi"
 nstlc:
 resources:
 requests:
 cpu: "5m"
 memory: "128Mi"
 limits:
 cpu: "2000m"
 memory: "1Gi"
 nstld:
 resources:
 requests:
 cpu: "5m"
 memory: "128Mi"
 limits:
 cpu: "2000m"
 memory: "1Gi"
 pam:
 resources:
 requests:
 cpu: "5m"
 memory: "512Mi"
 limits:
 cpu: "2000m"
 memory: "1Gi"
 rs:
 resources:
 requests:
 cpu: "2m"
 memory: "1Gi"
 limits:
 cpu: "4000m"
 memory: "8Gi"
 webdav:
 resources:
 requests:
 cpu: "2m"
 memory: "512Mi"
 limits:
 cpu: "2000m"
 memory: "2Gi"

 rms:
 resources:
 requests:
 cpu: "2m"
 memory: "128Mi"
 limits:
 cpu: "1000m"
 memory: "512Mi"
 rmsa:
 resources:
 requests:
 cpu: "2m"
 memory: "128Mi"
 limits:
 cpu: "1000m"
 memory: "512Mi"
 rmsb:
 resources:
 requests:
 cpu: "2m"
 memory: "128Mi"
 limits:
 cpu: "1000m"
 memory: "512Mi"

tenant/Chart.yaml#

apiVersion: v2
name: sample-tenant
description: |
 The sample tenant chart demonstrates how to use umbrella charts with default values,
 e.g. to define tenant templates
type: application
dependencies:
 - name: nplus-instance
 alias: instance
 version: "*-0"
 repository: "file://../../../charts/instance"
version: 1.0.0

tenant/README.md#



# sample-tenant

The sample tenant chart demonstrates how to use umbrella charts with default values,
e.g. to define tenant templates

## sample-tenant Chart Configuration

You can customize / configure sample-tenant by setting configuration values on the command line or in values files,
that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

### Template Functions

You can use template functions in the values files. If you do so, make sure you quote correctly (single quotes, if you have double quotes in the template,
or escaped quotes).

### Global Values

All values can be set per component, per instance or globally per environment.

Example: `global.ingress.domain` sets the domain on instance level. You can still set a different domain on a component, such as administrator.
In that case, simply set `ingress.domain` for the administrator chart and that setting will have priority:

- Prio 1 - Component Level: `ingress.domain`
- Prio 2 - Instance Level: `global.ingress.domain`
- Prio 3 - Environment Level: `global.environment.ingress.domain`

### Using Values in Templates

As it would be a lot of typing to write `.Values.ingress.domain | default .Values.global.ingress.domain | default .Values.global.environment.ingress.domain`in your
template code, this is automatically done by nplus. You can simply type `.this.ingress.domain` and you will get a condensed and defaulted version
of your Values.

So an example in your `values.yaml` would be:

administrator: waitFor: - ‘-service {{ .component.prefix }}nappljobs.{{ .Release.Namespace }}.svc.cluster.local:{{ .this.nappl.port }} -timeout 600’

Custom Probes Example

Mon, 01 Jan 0001 00:00:00 +0000

Custom Probes Example#

In this example, we show how to change the probes on the main container in a chart. Especially with nappl, it can happen that it takes longer in larger projects, so you may want to adjust the startup delay times or switch entirely to your own or different health checks.

In practice, the probes provided by the vendor are often not suitable for production environments. nplus ships with tested alternatives, but depending on your setup, you may still need to adjust them.

default

Mon, 01 Jan 0001 00:00:00 +0000

This is the most simple example: It renders a default instance wihout any values at all.

Files#

Download all files of this sample

build.sh#

#!/bin/bash
#
# This sample script builds the example as described. It is also used to build the test environment in our lab,
# so it should be well tested.
#

# Make sure it fails immediately, if anything goes wrong
set -e

# -- ENVironment variables:
# CHARTS: The path to the source code
# DEST: The path to the build destination
# SAMPLE: The directory of the sample
# NAME: The name of the sample, used as the .Release.Name
SAMPLE="default"
NAME="sample-$SAMPLE"

# Check, if we have the source code available
if [ ! -d "$CHARTS" ]; then
 echo "ERROR Building $SAMPLE example: The Charts Sources folder is not set. Please make sure to run this script with the full Source Code available"
 exit 1
fi
if [ ! -d "$DEST" ]; then
 echo "ERROR Building $SAMPLE example: DEST folder not found."
 exit 1
fi
if [ ! -d "$CHARTS/instance" ]; then
 echo "ERROR Building $SAMPLE example: Chart Sources in $CHARTS/instance not found. Are you running this script as a subscriber?"
 exit 1
fi

# Output what is happening
echo "Building $NAME"

# Create the manifest
mkdir -p $DEST/instance
helm template --debug \
 $NAME $CHARTS/instance > $DEST/instance/default.yaml

Deploying with Argo

Mon, 01 Jan 0001 00:00:00 +0000

Deploying with Argo#

the argo version of the instance#

Deployin with argoCD is straight forward, as there is a ready-to-run instance chart version for argo, that takes exactly the same values as the normal chart:

helm install \
 --values samples/application/empty.yaml \
 --values samples/environment/demo.yaml \
 sample-empty-argo nplus/nplus-instance-argo

Using Waves#

The instance chart already comes with pre-defined waves. They are good to go with (can be modified though):

nappl:
 meta:
 wave: 15

But: You might be annoyed by ArgoCD, when some services do not come up preventing other services to not be started at all since ArgoCD operates in Waves, so later services might not be deployed at all if an early wave services fails.

eon

Mon, 01 Jan 0001 00:00:00 +0000

eon#

Files#

Download all files of this sample

sharepoint.yaml#

components:
 sharepoint: false
 sharepointa: true
sharepointa:
 backendProtocol: https
 replicas: 1
 sharepoint:
 secret: sp-secret
 spHost: "https://eonos.sharepoint.com/"
 triggerProperty: "ToBeArchived"
 serviceBusQueueName: "itemstobearchived"
 serviceBusConnectionString: "Endpoint=sb://sharepointeventsqa.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=d06NW37Tu0bm+oXa6cov1PRMQbwdenUL0+ASbNv7ysk="
 serviceBusRetentionQueueName: "testqueue"
 serviceBusTopicNameConfigUpdate: "automaticsiteconfiguration"
 doCheckOut: "true"
 connector:
 idPropertyName: "sharepoint_id"
 parentIdPropertyName: "sharepoint_parentid"
 cTagPropertyName: "sharepoint_ctag"
 eTagPropertyName: "sharepoint_etag"
 webUrlPropertyName: "sharepoint_weburl"
 listItemIdPropertyName: "sharepoint_listitemid"
 stubIdPropertyName: "sharepoint_stubid"
 stubListItemIdPropertyName: "sharepoint_stublistitemid"
 sharePointCreatorPropertyName: "sharepoint_creator"
 sharePointCreatedPropertyName: "sharepoint_created"
 sharePointEditorPropertyName: "sharepoint_editor"
 sharePointEditedPropertyName: "sharepoint_lastmodified"
 sharePointChangeTokenPropertyName: "sharepoint_changetoken"
 nscaleRetentionPropertyName: "sharepoint_retention"
 nscaleExpirationPropertyName: "sharepoint_expiration"
 nscaleLegalHoldPropertyName: "sharepoint_legalhold"
 nscaleLegalHidePropertyName: "sharepoint_legalhide"
 nscaleGdprRelevantPropertyName: "sharepoint_gdpr_relevant"
 nappl:
 secret: sp-nappl-secret
 nscale:
 docArea: "SPARCHIVE"
 baseFolder: "where displayname='Root_Folder'"
 ingress:
 backendProtocol: https
 ssl:
 keystoreSecret: sp-keystore-secret
 keystore: "../conf/keystore.ks"
 doInitialCrawl: "true"
 parallelRequests: 15
 env:
 MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE: "*"
 CLIENTCERTPFX: "../conf/dms-corp-qa.intranet.eon.com.pfx"
 CLIENTCERTPEM: "../conf/dms-corp-qa.intranet.eon.com.pem"

Generic Mount Example

Mon, 01 Jan 0001 00:00:00 +0000

Generic Mount Example#

This allows you to mount any pre-provisioned PVs, secret or configMap 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>
 medium: <"Memory" to request a RAM Drive>

Mounting generic secrets or configMaps#

In this example, we create a secret with two sample files and a configMap with two sample files:

Grouping Instances

Mon, 01 Jan 0001 00:00:00 +0000

Grouping Instances#

Sometimes Instances become quite large with many components. If you work on them with multiple team members, you end up having to synchronize the deployment of the Instances.

You can easily rip large Instances apart using the group tag, joining multiple Instances into one group and making sure the NetworkPolicies are opened to pods from other Instances within the Instance Group.

global:
 instance:
 # -- despite the instance name, all components within this group will be prefixed
 # with the group (unless the group name and the environment name are not identical)
 # Also this makes sure the network policies are acting on the group, not on the instance.
 group: "sample-group"

You can query the instance group in your code with .instance.group.

hid

Mon, 01 Jan 0001 00:00:00 +0000

Highest ID#

This example shows how to configure storing the HID file in nscale Server Storage Layer:

global:
 # -- enables checking the highest DocID when starting the server.
 # this only makes sense, if you also set a separate volume for the highest ID
 # This is a backup / restore feature to avoid data mangling
 checkHighestDocId: "1"
 # -- sets the path of the highest ID file.
 dvCheckPath: "/opt/ceyoniq/nscale-server/storage-layer/hid"

We use the global section here to have it activated in all nstl instances defined.

High Availability

Mon, 01 Jan 0001 00:00:00 +0000

High Availability#

To gain a higher level of availability for your Instance, you can

create more Kubernetes Cluster Nodes
create more replicas of the nscale and nplus components
distribute those replicas across multiple nodes using anti-affinities

This is how:

helm install \
 --values samples/ha/values.yaml
 --values samples/environment/demo.yaml \
 sample-ha nplus/nplus-instance

The license and the storage layer server ids#

A nscale Server Storage Layer runs with a server id, and in a high availability setup each node needs its own. The sample therefore sets them explicitly, 4711 for nstla and 4712 for nstlb:

Imprint

Mon, 01 Jan 0001 00:00:00 +0000

Imprint#

42i GmbH
Zum Kurwald 17
33175 Bad Lippspringe
Germany

E-mail: info@42i.org

Managing director: Andreas Ahmann

nscale is a product and trademark of Ceyoniq Technology GmbH. nplus contains no nscale software, licenses or services; these are obtained directly from Ceyoniq.

initcontainers

Mon, 01 Jan 0001 00:00:00 +0000

Init Container#

This example shows the configuration of custom init container for any of the components:

nappl:
 initContainers:
 - name: myInit
 image: myImage
 command: [ "/startup.sh" ]

Files#

Download all files of this sample

values.yaml#

nappl:
 initContainers:
 - name: myInit
 image: myImage
 command: [ "/startup.sh" ]
nstl:
 initContainers:
 - name: myInit
 image: myImage
 command: [ "/startup.sh" ]

Installing Document Areas

Mon, 01 Jan 0001 00:00:00 +0000

Installing Document Areas#

Creating an empty document area while deploying an Instance#

This is the simplest sample, just the core services with an empty document area:

helm install \
 --values samples/application/empty.yaml \
 --values samples/environment/demo.yaml \
 empty nplus/nplus-instance

The empty Document Area is created with

components:
 application: true
 prepper: true
 
application:
 docAreas:
 - id: "Sample"
 run:
 - "/pool/downloads/sample.sh"

prepper:
 download:
 - "https://www.nplus.cloud/raw/assets/sample.tar.gz"

This turns on the prepper component, used to download a sample tarball from git. It will also extract the tarball into the downloads folder that is created on the pool automatically.

K8s namespace aka nplus environment

Mon, 01 Jan 0001 00:00:00 +0000

K8s namespace aka nplus environment#

nplus instances are deployed into K8s namespaces. Always. even if you do not specify a namespace, it uses a namespace: default.

In order to use this namespace for nplus instances, you need to deploy some shared nplus components into it, which are used by the instances. This is done by the environment chart:

helm install \
 --values demo.yaml \
 demo nplus/nplus-environment

After that, the K8s namespace is a valid nplus environment that can house multiple nplus instances.

memory: # No Limit but hardware

Mon, 01 Jan 0001 00:00:00 +0000

Assigning CPU and RAM#

You should assign resources to your components, depending on the load that you expect.

In a dev environment, that might be very little and you may be fine with the defaults.

in a qa or prod environment, this should be wisely controlled, like this:

nappl:
 resources:
 requests:
 cpu: "100m" # Minimum 1/10 CPU
 memory: "1Gi" # Minimum 1 GB
 limits:
 cpu: "2000m" # Maximum 2 Cores
 memory: "4Gi" # Maximum 4 GB. Java will see this as total.
 javaOpts:
 javaMinMem: "512m" # tell Java to initialize the heap with 512 MB
 javaMaxMem: "2048m" # tell Java to use max 2 GB of heap size

Write the quantities the way Kubernetes stores them. The API normalises memory values: 1024Mi comes back as 1Gi, 2048Mi as 2Gi. Helm sends what you wrote, the cluster reports what it stored - and a GitOps tool that compares the two, like Argo CD, then shows the application as OutOfSync forever, on a difference that does not exist. Prefer 1Gi over 1024Mi, 2Gi over 2048Mi. Values that are already in their smallest form, such as 512Mi or 100m, stay as they are.

nplus-application

Mon, 01 Jan 0001 00:00:00 +0000

nplus-application#

nplus Application, used to install Apps and Customizations into the nscale Application Layer.

AppInstaller#

In order to install Apps, you will need a matching AppInstaller. This can be downloaded from the Ceyoniq Service Portal. Once you have it, copy it the pool folder (or any other place where the application chart has access to):

kubectl cp app-installer-9.0.1202.jar nplus-toolbox-0:/conf/pool

Ceyoniq Smart Business Apps (SBS)#

The SBS Apps are automatically downloaded from the official Ceyoniq nstore by a job in the nplus environment, if you switched it on during the environment installation:

nplus-cluster

Mon, 01 Jan 0001 00:00:00 +0000

nplus-cluster#

Installs Cluster-Wide Resources such as CRDs

nplus-component-administrator

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-administrator#

nscale Administrator, providing the Web Version of the Administrator to be used in the Instance

nplus-component-administrator Chart Configuration#

You can customize / configure nplus-component-administrator by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-component-cmis

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-cmis#

nscale CMIS Connector, provides a CMIS Interface to the Instance

nplus-component-cmis Chart Configuration#

You can customize / configure nplus-component-cmis by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-component-database

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-database#

Postgres Database, deploys a DEV or TESTING environment DB

nplus-component-database Chart Configuration#

You can customize / configure nplus-component-database by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-component-erpcmis

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-erpcmis#

nscale ERP CMIS, providing SAP S/4 HANA Public Cloud Archive Access

nplus-component-erpcmis Chart Configuration#

You can customize / configure nplus-component-erpcmis by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-component-erpproxy

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-erpproxy#

nscale ERP Proxy, providing SAP Archive Link access to alien Archive Components

Single Server with multiple Replicas (and same Config)#

In the instance, configure

components:
 sharepoint: true
sharepoint:
 replicas: 2

Multiple Servers with different Configs#

components:
 sharepointa: true
 sharepointb: true
sharepointa:
 replicas: 1
sharepointb:
 replicas: 1

this way, you will have two sharepoint instances with different config.

nplus-component-erpproxy Chart Configuration#

You can customize / configure nplus-component-erpproxy by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

nplus-component-ilm

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-ilm#

nscale ILM Connector, providing a certified SAP ILM interface

nplus-component-ilm Chart Configuration#

You can customize / configure nplus-component-ilm by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-component-mon

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-mon#

nscale Monitoring Console, used to provide sensor information from all components to dashboards

Generelle Informationen#

Wenn Ressourcen im Admin hinzugefügt werden, müssen nachträglich die Namen der Server geändert werden. Diese heißen üblicherweise -nappl oder -nstl. Also z.B. rms-nappl und rms-nstl

nplus-component-mon Chart Configuration#

You can customize / configure nplus-component-mon by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

nplus-component-nappl

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-nappl#

nscale Server Application Layer, the central component in the nscale ecosystem

nplus-component-nappl Chart Configuration#

You can customize / configure nplus-component-nappl by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-component-nstl

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-nstl#

nscale Server Storage Layer, virtualizing the storage to be used by the nscale Server

Server Ids#

if you use nstlHA, both server must have unique server IDs. Since the probaly use the same license file, you can set it via

nstla:
 serverId: 4711
nstlb:
 serverId: 4712

to make this work, you must have a license without nstl ServerID in it.

High Availability#

nscale Server Storage Layer does not support multiple replicas because of configuration restraints. To get HA, nplus defines nstl[a-d].

nplus-component-pam

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-pam#

nscale Process Automation Modeler, providing Web UI Modeler for PAP

nplus-component-pam Chart Configuration#

You can customize / configure nplus-component-pam by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-component-pipeliner

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-pipeliner#

nscale Pipeliner, the mass import / export tool of nscale

nplus-component-pipeliner Chart Configuration#

You can customize / configure nplus-component-pipeliner by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-component-postgres

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-postgres#

Postgres Database, deploys the official Postgres image

nplus-component-postgres Chart Configuration#

You can customize / configure nplus-component-postgres by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

Template Functions#

You can use template functions in the values files. If you do so, make sure you quote correctly (single quotes, if you have double quotes in the template, or escaped quotes).

nplus-component-rms

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-rms#

nplus Remote Management Server incl. RMS and Access Proxy

Generelle Informationen#

Das RMS Chart simuliert einen Server, auf dem alle nscale Komponenten installiert sind. Dieser kann dann per nscale Administrator zugegriffen werden. Der Ingress dafür ist admin..

Das funktioniert nur mit RMS 2 und einem neuen Admin ab Version 9.2

Bash into#

kubectl exec --stdin --tty rms-rms-0 -- bash

Logs#

kubectl logs rms-rms-0 -c proxy
kubectl logs rms-rms-0 -c rms

nplus-component-rms Chart Configuration#

You can customize / configure nplus-component-rms by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

nplus-component-rs

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-rs#

nscale Rendition Server, providing means to format-convert common file types

nplus-component-rs Chart Configuration#

You can customize / configure nplus-component-rs by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-component-sharepoint

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-sharepoint#

nscale SharePoint Connector, providing SP archiving to the Instance

Single Server with multiple Replicas (and same Config)#

In the instance, configure

components:
 sharepoint: true
sharepoint:
 replicas: 2

Multiple Servers with different Configs#

components:
 sharepointa: true
 sharepointb: true
sharepointa:
 replicas: 1
sharepointb:
 replicas: 1

this way, you will have two sharepoint instances with different config.

Cluster Service#

in multi server mode, the Instance Chart deploys a sharepoint cluster service that balances across sharepoint A and B.

nplus-component-web

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-web#

nscale Web, providing a modern Web UI to nscale users

tls / https#

nscale Web is not automatically enabling tls / https and also does currently not automatically generate a certificate for tls.

However, the nplus Web Chart does, and stores it in conf/keystore.jks. Additionally, if there is no server.xml in the conf directory, nplus copies a custom server.xml to conf, that has tls enabled and references conf/keystore.jks.

If you already have a running web componenent, and want to use tls with web, you will need to edit this file manually. See ITSMSD-8772.

nplus-component-webdav

Mon, 01 Jan 0001 00:00:00 +0000

nplus-component-webdav#

nscale WebDAV Connector, providing a standard WebDAV interface to the Instance

Usage#

https://empty.lab.nplus.cloud/dav/nscalealinst1/Sample

nplus-component-webdav Chart Configuration#

You can customize / configure nplus-component-webdav by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-environment

Mon, 01 Jan 0001 00:00:00 +0000

nplus-environment#

Installs Namespace-Wide Resources such as the conf PVC, the toolbox and the nplus monitoring service

This Environment Chart provides a common config pool and administrative tools to operate all nplus instances in this namespace. There must be exactly one deployed instance of this environment chart per kubernetes namespace. Without the environment, the instance and component charts will fail to deploy.

It also deployes the operator, which is a monitoring component to observe all instances and provide healthyness information to the administrator and third party dashboards

nplus-environment-backend

Mon, 01 Jan 0001 00:00:00 +0000

nplus-environment-backend#

Installs Namespace-Wide Resources such as the conf PVC and the ptemp PVC

nplus-environment-backend Chart Configuration#

You can customize / configure nplus-environment-backend by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-environment-dav

Mon, 01 Jan 0001 00:00:00 +0000

nplus-environment-dav#

Provides WebDAV access to environment resources such as the conf PVC and the ptemp PVC

nplus-environment-dav Chart Configuration#

You can customize / configure nplus-environment-dav by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-environment-operator

Mon, 01 Jan 0001 00:00:00 +0000

nplus-environment-operator#

Installs the nplus operator managin the custom resource definitions for nplus and nscale

nplus-environment-operator Chart Configuration#

You can customize / configure nplus-environment-operator by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-environment-toolbox

Mon, 01 Jan 0001 00:00:00 +0000

nplus-environment-toolbox#

Installs the environment toolbox with git and nstore downloader installed, also serving as target for pool copy actions in the pipeline

nplus-environment-toolbox Chart Configuration#

You can customize / configure nplus-environment-toolbox by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-instance

Mon, 01 Jan 0001 00:00:00 +0000

nplus-instance#

nplus Instance, an umbrella chart for orchestrating the components in a nplus Instance

Single Instance Mode#

If you want to separate tenants on your system not only by instance but also by environment / namespace, you can run nplus in single instance mode.

SIM (Single Instance Mode) lets you deploy your instance including all components of the environment in one single chart.

Steps to turn on single instance mode:

nplus-instance-argo

Mon, 01 Jan 0001 00:00:00 +0000

nplus-instance-argo#

nplus Instance ArgoCD Edition, supporting the deployment of npus Instances through ArgoCD

nplus-instance-argo Chart Configuration#

You can customize / configure nplus-instance-argo by setting configuration values on the command line or in values files, that you can pass to helm. Please see the samples directory for details.

In case there is no value set, the key will not be used in the manifest, resulting in values taken from the config files of the component.

nplus-prepper

Mon, 01 Jan 0001 00:00:00 +0000

nplus-prepper#

nplus Prepper, used to deploy assets prior to component deployment

The Prepper prepares everything required for the Instance to work as intended. It is very much like the Application, except that it does not connect to any nscale component (as they do not yet run by the time the prepper executes). But just like the Application, the Prepper is able to download assets and run scripts.

You can add this to your (instance-) deployment:

OpenTelemetry

Mon, 01 Jan 0001 00:00:00 +0000

OpenTelemetry#

You can use Annotations für Telemetry Operators such as Open Telemetry to inject their Agents into the Pods. To do so, you can either add the annotations manually to the components, like this:

nappl:
 template:
 annotations:
 instrumentation.opentelemetry.io/inject-java: "true"
 instrumentation.opentelemetry.io/java-container-names: "application-layer"

or alternatively, you can turn on the built in functionality for the supported telemetry services.

This is an example for OpenTelemetry:

global:
 telemetry:
 openTelemetry: true
 serviceName: "{{ .this.meta.type }}-{{ .instance.name }}-{{ .instance.stage }}"
 meta:
 stage: "dev"

This will automatically set the correct settings as seen above.

Pinning Versions

Mon, 01 Jan 0001 00:00:00 +0000

Pinning Versions#

Old Version#

If you want to test rolling updates and upgrades to a new minor version, check out the e90 sample:

This sample installs version 9.0.1400 for testing. Because cluster node discovery changed with a newer jGroups version in nscale, the chart detects the older version and enables the legacy discovery mechanism so the Pod can find its peers on versions prior to 9.1.1200.

helm install \
 --values samples/empty.yaml \
 --values samples/demo.yaml \
 --values versions/9.0.1400.yaml \
 sample-e90 nplus/nplus-instance

New Version Sample#

Some nscale versions are license compatible, meaning a 9.1 license file can also run nscale 9.0 software. But that is not always the case.

Preparing the K8s Cluster

Mon, 01 Jan 0001 00:00:00 +0000

Preparing the K8s Cluster#

nplus Charts bring some custom resources, Application, Instance and Component. they are created during deployment of a chart and then updated by the environment operator every time the status changes.

To make this work, you will need to have the Custom Resource Definitions applied to your cluster prior to deploying any environment or component. This deployment is handled by the Cluster Chart.

helm install nplus/nplus-cluster

The CRDs are grouped into nscale and nplus (both synonym), so that you can either query for

Privacy

Mon, 01 Jan 0001 00:00:00 +0000

Privacy#

This website is a static site. It sets no cookies, uses no tracking and loads no resources from third parties. The search runs entirely in your browser.

When you visit the site, the web server processes the technically necessary connection data (IP address, time, requested page, browser identification) to deliver the pages and to protect the server against abuse. This data is not merged with other data (Art. 6 (1) (f) GDPR).

Security

Mon, 01 Jan 0001 00:00:00 +0000

Security#

All the standards#

There are several features that will enhance the security of your system:

all components are running rootless by default
all components drop all privileges
all components deny escalation
all components have read only file systems
Access is restricted by NetworkPolicies

Additional: The backend Protocol#

Additionally, you can increase security by encrypting communication in the backend. Depending on your network driver, this might already been done automatically beween the Kubernetes Nodes. But you can double that even within a single node by switching the backend Protocol to https:

Sharing Instances

Mon, 01 Jan 0001 00:00:00 +0000

Some organisations have multiple tenants that share common services, like nscale Rendition Server or have a common IT department, thus using only a single nscale Monitoring Console acress all tenants.

This is the Central Services Part:

helm install \
 --values samples/shared/centralservices.yaml \
 --values samples/environment/demo.yaml \
 sample-shared-cs nplus/nplus-instance

And this is the tenant using the Central Services:

helm install \
 --values samples/shared/shared.yaml \
 --values samples/environment/demo.yaml \
 sample-shared nplus/nplus-instance

If you enable security based on Network Policies, you need to add additional Policies to allow access. Please see shared-networkpolicy.yaml and centralservices-networkpolicy.yaml as an example.

Single-Instance-Mode

Mon, 01 Jan 0001 00:00:00 +0000

Single-Instance-Mode#

If you choose to separate tenants on your system not only by nplus Instances but also by nplus Environments, thus running each tenant in a separate Kubernetes Namespace, you do not need to create an nplus Environment first, but you can rather enable the nplus Environment Components within your instance:

components:
 sim:
 dav: true
 backend: true
 operator: true
 toolbox: true

Steps to run a SIM Instance:

Create the namespace and the necessary secrets to access the repo, registry as well as the nscale license file

SIM_NAME="empty-sim"

kubectl create ns $SIM_NAME
kubectl create secret docker-registry nscale-cr \
 --namespace $SIM_NAME \
 --docker-server=ceyoniq.azurecr.io \
 --docker-username=$NSCALE_ACCOUNT \
 --docker-password=$NSCALE_TOKEN
kubectl create secret docker-registry nplus-cr \
 --namespace $SIM_NAME \
 --docker-server=git.42i.org \
 --docker-username=$NPLUS_ACCOUNT \
 --docker-password=$NPLUS_TOKEN
kubectl create secret generic nscale-license \
 --namespace $SIM_NAME \
 --from-file=license.xml=$NSCALE_LICENSE

Deploy the Instance

helm install \
 --values lab.yaml \
 --values single-instance-mode.yaml \
 --namespace $SIM_NAME \
 $SIM_NAME nplus/nplus-instance

If you do not have any Application that requires assets such as scripts or apps, you are good to go with this.

Specifics of the Sharepoint Connector

Mon, 01 Jan 0001 00:00:00 +0000

Specifics of the Sharepoint Connector#

Normally, you will have different configurations if you want multiple Sharepoint Connectors. This makes the nsp somewhat special:

Multi Instance HA Sharepoint Connector#

This sample shows how to setup a sharepoint connector with multiple instances having different configurations for archival, but with High Availability on the retrieval side.

SharePoint is one of the few components for which is is quite common to have multiple instances instead of replicas. Replicas would include, that the configuration for all pods is identical. However, you might want to have multiple configurations as you also have multiple sharepoint sites you want to archive.

Static Volumes

Mon, 01 Jan 0001 00:00:00 +0000

Static Volumes#

Assigning PVs#

For security reasons, you might want to use a storage class that does not perform automatic provisioning of PVs. In that case, you want to reference a pre-created volume in the PVC. In nplus, you can do so by setting the volumeName in the values.

Please review values.yaml as an example:

database:
 mounts:
 data:
 volumeName: "pv-{{ .component.fullName }}-data"
nstl:
 mounts:
 data:
 volumeName: "pv-{{ .component.fullName }}-data"

You can also set the environment config volume. Please refer to the environment documentation for that.

Switching to the Official Postgres Image

Mon, 01 Jan 0001 00:00:00 +0000

Switching to the Official Postgres Image#

If you want to move from the Bitnami Postgres image to the official Postgres image, set:

components:
 database: false
 postgres: true
global:
 database:
 url: "jdbc:postgresql://{{ .component.prefix }}postgres:5432/{{ .this.database.name }}"

in the values file. This will instantiate the official Postgres image. All values are identical.

You can also run both components side-by-side to perform migrations.

Make sure you set the database URL to the new DB when you are done.

Traefik

Mon, 01 Jan 0001 00:00:00 +0000

Traefik#

If Traefik is the ingress controller of your cluster, nplus offers two ways to publish an instance. Both are fully supported — they differ in what kind of objects the charts create, and therefore in how much of Traefik you can reach from the values.

	`backend: traefik`	`provider: traefik`
Objects	`Ingress` + a few `Middleware`	`IngressRoute`, `Middleware`, `ServersTransport`
Configured by	annotations on the Ingress	native CRD fields
Sticky cookie	annotation, name only	native, incl. `maxAge`, `path`, `sameSite`
Body size, timeouts	not available	`maxRequestBodyBytes`, `responseHeaderTimeout`
CORS, rate limiting	not available	per component
Own middlewares	not attachable	`ingress.traefik.middlewares`
Denied paths	routed to the `void` service	answered with 403
Portable to another controller	yes, it stays an Ingress	no, Traefik only

Rule of thumb: take the annotations variant if you want to keep the manifests portable and only need the basics. Take the native variant if you actually want to configure Traefik — body limits, timeouts, CORS, rate limiting — or if you want to attach middlewares of your own.

Using detached applications

Mon, 01 Jan 0001 00:00:00 +0000

Using detached applications#

All the other samples use an application that is deployed inside of an instance. However, you can also deploy an application detached from the instance as a solo chart.

The reason for this is, that you

can update the instance without running the application update
update the application without touching the instance
have multiple applications deployed within one instance

There are two major things you need to do:

Using Object Stores

Mon, 01 Jan 0001 00:00:00 +0000

Using Object Stores#

Blobstores aka Objectstores have a REST Interface that you can upload your Payload to and receive an ID for it. They are normally structured into Buckets or Containers to privide some sort of pooling payload within the store.

The nscale Server Storage Layer supports multiple brands of objectstores, the most popular being Amazon S3 and Microsoft Azure Blobstore.

In order to use them, you need to

get an account for the store
configure the nstl with the url, credentials etc.
Add firewall rules to access to store

Have a look at the sample files

Using the ERP Proxy

Mon, 01 Jan 0001 00:00:00 +0000

Using the ERP Proxy#

You can customize the usage of the ERP Proxy by setting the following values in the values.yaml file:

components:
 erpproxya: true
 erpproxyb: true
erpproxya:
 ingress:
 contextPath: /proxya
 xsap:
 url: "{{ printf \"%s/%s\" ($.this.nappl).instance \"xsap/cs/sample1\"}}"
erpproxyb:
 ingress:
 contextPath: /proxyb
 xsap:
 url: "{{ printf \"%s/%s\" ($.this.nappl).instance \"xsap/cs/sample2\"}}"

Files#

Download all files of this sample

build.sh#

#!/bin/bash
#
# This sample script builds the example as described. It is also used to build the test environment in our lab,
# so it should be well tested.
#

# Make sure it fails immediately, if anything goes wrong
set -e

# -- ENVironment variables:
# CHARTS: The path to the source code
# DEST: The path to the build destination
# SAMPLE: The directory of the sample
# NAME: The name of the sample, used as the .Release.Name
# KUBE_CONTEXT: The name of the kube context, used to build this sample depending on where you run it against. You might have different Environments such as lab, dev, qa, prod, demo, local, ...

# Check, if we have the source code available
if [ ! -d "$CHARTS" ]; then
 echo "ERROR Building $SAMPLE example: The Charts Sources folder is not set. Please make sure to run this script with the full Source Code available"
 exit 1
fi
if [ ! -d "$DEST" ]; then
 echo "ERROR Building $SAMPLE example: DEST folder not found."
 exit 1
fi
if [ ! -d "$CHARTS/instance" ]; then
 echo "ERROR Building $SAMPLE example: Chart Sources in $CHARTS/instance not found. Are you running this script as a subscriber?"
 exit 1
fi

# Set the Variables
SAMPLE="erpproxy"
NAME="sample-$SAMPLE"

# Output what is happening
echo "Building $NAME"

# Create the manifest
mkdir -p $DEST/instance
helm template --debug \
 --values $SAMPLES/application/empty.yaml \
 --values $SAMPLES/environment/$KUBE_CONTEXT.yaml \
 --values $SAMPLES/resources/$KUBE_CONTEXT.yaml \
 --values $SAMPLES/erpproxy/values.yaml \
 $NAME $CHARTS/instance > $DEST/instance/$SAMPLE.yaml

values.yaml#

components:
 erpproxya: true
 erpproxyb: true
erpproxya:
 ingress:
 contextPath: /proxya
 xsap:
 url: "{{ printf \"%s/%s\" ($.this.nappl).instance \"xsap/cs/sample1\"}}"
erpproxyb:
 ingress:
 contextPath: /proxyb
 xsap:
 url: "{{ printf \"%s/%s\" ($.this.nappl).instance \"xsap/cs/sample2\"}}"

Using the gateway API

Mon, 01 Jan 0001 00:00:00 +0000

Using the gateway API#

you can use the gateway api instead of the default ingress api.

to do so, simply switch the provider on either environment or instance level:

global:
 ingress:
 provider: gateway

all ingress parameters are taken into the gateway configuration, such as the class etc.

Files#

Download all files of this sample

build.sh#

#!/bin/bash
#
# This sample script builds the example as described. It is also used to build the test environment in our lab,
# so it should be well tested.
#

# Make sure it fails immediately, if anything goes wrong
set -e

# -- ENVironment variables:
# CHARTS: The path to the source code
# DEST: The path to the build destination
# SAMPLE: The directory of the sample
# NAME: The name of the sample, used as the .Release.Name
# KUBE_CONTEXT: The name of the kube context, used to build this sample depending on where you run it against. You might have different Environments such as lab, dev, qa, prod, demo, local, ...

# Check, if we have the source code available
if [ ! -d "$CHARTS" ]; then
 echo "ERROR Building $SAMPLE example: The Charts Sources folder is not set. Please make sure to run this script with the full Source Code available"
 exit 1
fi
if [ ! -d "$DEST" ]; then
 echo "ERROR Building $SAMPLE example: DEST folder not found."
 exit 1
fi
if [ ! -d "$CHARTS/instance" ]; then
 echo "ERROR Building $SAMPLE example: Chart Sources in $CHARTS/instance not found. Are you running this script as a subscriber?"
 exit 1
fi

# Set the Variables
SAMPLE="gateway"
NAME="sample-$SAMPLE"

# Output what is happening
echo "Building $NAME"

# Create the manifest
mkdir -p $DEST/instance
helm template --debug \
 --values $SAMPLES/application/empty.yaml \
 --values $SAMPLES/environment/$KUBE_CONTEXT.yaml \
 --values $SAMPLES/resources/$KUBE_CONTEXT.yaml \
 --values $SAMPLES/$SAMPLE/values.yaml \
 $NAME $CHARTS/instance > $DEST/instance/$SAMPLE.yaml

values.yaml#

global:
 ingress:
 provider: gateway

nplus

Versioning

Versioning#

nplus versions#

Quickstart

nplus Quickstart Guide#

Quickstart with Argo CD

Adding ArgoCD#

FAQ

Frequently Asked Questions (FAQ)#

How do I add my custom Generic Base App (GBA) to the deployment?#

I do not find any of my custom objects (roles, classes, …) from my GBA in the system. Is there an install log file that I can check?#

nscale versions

nscale versions#

Operations

Day 1 Ops: Install, Update, Uninstall#

Release history

Version History#

September 2026, Beta 200#

September 2026, Beta 199#

September 2026, Beta 198#

September 2026, Beta 197#

August 2026, Beta 196#

August 2026, Beta 195#

August 2026, Beta 194#

March 2026, Beta 193#

March 2026, Beta 192#

February 2026, Beta 191#

February 2026, Beta 190#

February 2026, Beta 189#

February 2026, Release 1.4.1303#

February 2026, Beta 187#

January 2026, Beta 186#

November 2025, Beta 185#

October 2025, Beta 183#

September 2025, Beta 182#

August 2025, Beta 181#

July 2025, Beta 180#

May 2025, Beta 178/179#

May 2025, Beta 177#

April 2025, Beta 176#

April 2025, Beta 175#

February 2025, Beta 174#

February 2025, Beta 173#

February 2025, Release 1.3.1400#

January 2025, Beta 171#

January 2025, Beta 170#

January 2025, Beta 169#

January 2025, Beta 168#

January 2025, Beta 167#

December 2024, Beta 166#

December 2024, Beta 164#

December 2024, Beta 163#

December 2024, Beta 162#

December 2024, Beta 161#

November 2024, Beta 160#

November 2024, Beta 159#

November 2024, Beta 158#

October 2024, Beta 157#

October 2024, Beta 156#

October 2024, Beta 155#

September 2024, Release 1.2.1500#

August 2024, Release 1.2.1400#

(auto-) certificates and the pitfalls of *.this*

(auto-) certificates and the pitfalls of .this#

(virtual-) Remote Management Server

(virtual-) Remote Management Server#

chart

chart#

Files#

build.sh#

resources.yaml#

tenant/Chart.yaml#

tenant/README.md#

Custom Probes Example

Custom Probes Example#

default

Files#

build.sh#

Deploying with Argo

(auto-) certificates and the pitfalls of .this

K8s namespace aka nplus environment