Public Information

This commit is contained in:
2025-01-24 16:18:47 +01:00
commit 0bd2038c86
449 changed files with 108655 additions and 0 deletions

140
README.md Normal file
View File

@@ -0,0 +1,140 @@
![logo_nplus](assets/logo_nplus.svg)
The *nscale Plus Pack* (abbreviated as *nplus*) provides tools and instructions to deploy the [Ceyoniq](www.ceyoniq.com) *Enterprise Information Management* system [nscale](https://ceyoniq.com/produkte/) in a **multi-tenant** and **highly available** runtime environment in an **automated manner**. Additionally, the original **components are enhanced** to address common **enterprise requirements**.
*nplus* is a **subscription**. The subscriber gains access to all *nplus* resources, ensuring an easy way to **protect their investment**.
*nplus* does not include any nscale software, licenses or services, which are still to be obtained directly from Ceyoniq.
## TL;DR
Use `helm install` to install an nplus Instance. Setting the domain name is optional, but nplus will automatically generate an ingress including a certificate for you.
If you have *cert-manager* installed, it will issue a certificate for you. If not, nplus will generate a self-signed certificate.
```bash
helm install myinstance \
--set global.ingress.domain=myinstance.demo.nplus.cloud \
--set global.ingress.issuer=nplus-issuer \
nplus/nplus-instance
```
If you prefer to have *ArgoCD* perform the installation (instead of helm), you can use the *ArgoCD* chart to add the Argo Application:
```bash
helm install \
--set global.ingress.domain=myinstance-argo.demo.nplus.cloud \
--set global.ingress.issuer=nplus-issuer \
myinstance-argo nplus/nplus-instance-argo
```
You can check the status of the instance using:
```bash
# kubectl get instance
NAME HANDLER VERSION TENANT STATUS
myinstance Helm 9.1.1501 default starting
```
And the component status with:
```bash
# kubectl get components
NAME INSTANCE COMPONENT VERSION STATUS
myinstance-nstl myinstance nstl 9.1.1200 healthy
myinstance-rs myinstance rs 9.1.1300 healthy
myinstance-database myinstance database 15 healthy
myinstance-nappl myinstance nappl 9.1.1501 healthy
myinstance-web myinstance web 9.1.1500 healthy
myinstance-administrator myinstance administrator 9.1.1500 healthy
```
You can check the log files of the *Application Layer* for instance by typing:
```bash
# kubectl logs -l nplus/instance=myinstance,nplus/component=nappl
```
Uninstall myinstance using the following command:
```bash
helm uninstall myinstance
```
## Concept
***nplus*** includes **helm charts** for individual components and umbrella charts orchestrating these components. It can be installed multiple times within a **Kubernetes cluster**, once **per namespace**. This allows the use of multiple separate *nplus* environments in a single Kubernetes cluster. For example, different **stages** (*DEV*, *QA*, *PROD*, etc.) or **tenants** (*A GmbH*, *B AG*, *C GbR*, ...) could be placed in different namespaces.
With appropriate namespace separation, environments cannot see each other. However, it is optionally possible to create a separate namespace for **central services**, such as the *nscale Rendition Server* or the *nscale Storage Layer*, to be used across namespaces if desired.
Within a Kubernetes namespace, the ***nplus environment*** manages any number of **instances**, **components** and **applications**:
- An ***instance*** is a group of ***nscale**-*, ***nplus**-* and optionally ***open source**-* **components**, for example, an *nscale Application Layer* or a *KeyCloak* service. *nplus* includes separate, self-contained helm charts for each individual component, allowing a component to be deployed manually outside of an *instance*, although this is not recommended.
- ***Applications*** are units that optionally bring *configurations* and *customizations* into the *instance*. This could include creating a document area or installing a customer record management via a ***Generic Base App***. Even ***smart apps*** can be packaged in applications. In the subscriber area, you find examples of *applications*, which are helm charts to transport your individual project specifics into an instance.
If you have custom components, such as an API component for business applications, you can also package them into an application to install them with the suite.
For **GitOps projects**, all charts are also available as **ArgoCD** variants.
A **central storage** for the **configuration data** of individual *components* is provided for each *nplus environment*. This central storage is versioned using **git**. All config files from all applications of an installation are stored here.
## Features
For operation in a Kubernetes cluster, *nplus* provides:
- Versioned *helm charts* for all *nscale* components for installation, updating, and uninstallation.
- The nscale components (Application Layer, Storage Layer, Web, CMIS, etc.) can be grouped into *instances* in any combination.
- Multiple *instances* can run in a Kubernetes namespace (e.g., *Tenant1*, *Tenant2*, and *CentralServices*).
- A namespace can represent either a tenant (e.g., *Sales*) or a stage (e.g., *prod*, *qa*, or *dev) if running multiple stages on one cluster.
- Umbrella charts for complex environments, including:
- Optional LDAP directory with openLDAP.
- Optional central Single Sign-On with Multi-Factor Authentication using KeyCloak.
- Optional PostgreSQL database.
- Optional S3 connection for the Storage Layer.
- Optional Azure Blob connection for the Storage Layer.
- All charts are also available in an *argoCD* variant to integrate them into a GitOps deployment pipeline.
- Support for AppDynamics.
- Support for security tools, especially Illumio, Cilium, or Calico.
- Support for snc (for accessing SAP systems).
- Support for cert-manager for automatic TLS certificate generation.
- A separate application chart (*nplus Application*) for deploying and updating solutions.
- Usability of the classic *nscale Administrator* in a K8s DEV environment, eliminating the need for developers and administrators to adapt.
- Umbrella charts with tenant templates that can include and consolidate applications, solutions, and other external tools. Installing, uninstalling, or updating such tenants based on a template can then be done in a single line.
- Use of dedicated Application Layers for jobs, SAP, and users. For each use case, any number of replicas can be specified.
- Use of dedicated nscale Web instances for different departments, such as Department A and Department B. This allows loading different snippets or applying different SSO rules for each department.
### Licensing
The subscription credentials for *nplus* include access to the *nplus* (container) registry, the *nplus* (helm) repository, the *nplus* online documentation, and the *nplus* license from 42i GmbH.
*nscale* must be obtained and licensed through the manufacturer (*Ceyoniq Technology GmbH*) as usual and is linked by *nplus*. You need access to the *nscale Container Registry* and a suitable *license.xml* for the instance.
### Versioning
The chart version of the *nplus* and *nplus-argocd* charts corresponds to the *nscale Application Layer* version. They include references to the components approved for this *nscale* version. This ensures that you always get the official versions from Ceyoniq in the official combination. This behavior can be individually adjusted, for example, if a web client needs to be tested with the latest version of the previous month's NAPPL.
The (helm) app version corresponds to the helm git tag.
The chart version of the components (*nappl*, *web*, ...) corresponds to the respective image version to pin them exactly. All charts can be used individually but require a suitable runtime environment (*nplus*) to run. They do not work outside of *nplus*. Within an *nplus* environment, additional individual components can be easily started.
# Subscriber Area
- The changelog is kept in the [HISTORY.md](/subscription/helm/src/branch/master/HISTORY.md).
- More information, all source code, and samples can be found at the [official nplus repo](/subscription/helm).