Samples on nplus

(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:

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.

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

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

Samples on nplus

(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

Deploying with Argo#

the argo version of the instance#

Using Waves#

eon

eon#

Files#

sharepoint.yaml#

Generic Mount Example

Generic Mount Example#

Mounting generic secrets or configMaps#

Grouping Instances

Grouping Instances#

hid

Highest ID#

High Availability

High Availability#

The license and the storage layer server ids#

initcontainers

Init Container#

Files#

values.yaml#

Installing Document Areas

Installing Document Areas#

Creating an empty document area while deploying an Instance#

K8s namespace aka *nplus environment*

K8s namespace aka nplus environment#

memory: # No Limit but hardware

Assigning CPU and RAM#

OpenTelemetry

OpenTelemetry#

Pinning Versions

Pinning Versions#

Old Version#

New Version Sample#

Preparing the K8s Cluster

Preparing the K8s Cluster#

Security

Security#

All the standards#

Additional: The backend Protocol#

Sharing Instances

Sharing Instances#

Single-Instance-Mode

Single-Instance-Mode#

Specifics of the Sharepoint Connector

Specifics of the Sharepoint Connector#

Multi Instance HA Sharepoint Connector#

Static Volumes

Static Volumes#

Assigning PVs#

Switching to the Official Postgres Image

Switching to the Official Postgres Image#

Traefik

Traefik#

Using detached applications

Using detached applications#

Using Object Stores

Using Object Stores#

Using the ERP Proxy

Using the ERP Proxy#

Files#

build.sh#

(auto-) certificates and the pitfalls of .this

K8s namespace aka nplus environment