Public Information
This commit is contained in:
140
README.md
Normal file
140
README.md
Normal file
@@ -0,0 +1,140 @@
|
||||

|
||||
|
||||
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).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user