2.5. Deployment view#
This section provides a deployment views for the functional components of Nubus for Kubernetes.
You need to know the concept of pods and jobs in Kubernetes and what a Helm Chart is. Pods are the smallest deployable units of computing that you can create and manage. A job creates one or more pods and continues to retry running the pods until a specified number of them successfully ends.
The deployment view of Nubus consists of several figures, because one single figure would contain too many elements and would be hard to read. Each component has its own deployment view. Their common concept is the application component Univention Nubus for Kubernetes.
The views follow the same pattern. A Helm Chart locates in a container registry and references Docker images in a container registry. Helm Chart and Docker image realize a pod or a job in the Kubernetes cluster. A pod or a job realizes an application component in Nubus. The realization relationship represents that an element plays a critical role in the creation, or operation of a more abstract element. An application component belongs to a functional component that’s part of Nubus for Kubernetes.
See also
- Pods | Kubernetes
for more information about pods, what they are and how to work with them.
- Jobs | Kubernetes
for more information about jobs and their role in workload management.
- Helm | Charts
for more information about Helm Charts.
Information about used notation
This section uses concepts from the ArchiMate enterprise architecture modeling notation across the application and technology layers.
From the application layer it uses the following concepts:
Application Component
Application Interface
Application Process
Application Function
Data Object
From the technology layer it uses the following concepts:
System Software
Artifact
Node
From the relationships it uses the following concepts:
Composition
Aggregation
Realization
Assignment
Flow
Serving
For more information on these ArchiMate concepts, refer to the following sections in Univention Corporate Server Architecture [2]:
2.5.1. Registries for Helm Charts and images#
Fig. 2.25 shows the container registries that provide Helm Charts and images for Nubus.
Most Helm Charts come from artifacts.software-univention.de
and
docker.io
.
Most images come from artifacts.software-univention.de
and docker.software-univention.de
, both operated by Univention.
Some artifacts come from docker.io
.
The deployment views show which registry provides the respective Helm Charts and images.
When you install Nubus for Kubernetes, Helm loads the Charts and the images from these registry locations.
See also
- Deployment in Univention Nubus for Kubernetes - Operation Manual [1]
for more information about requirements and how to install Nubus for Kubernetes.
2.5.3. Directory Manager#
Fig. 2.27 shows the deployment view for the Directory Manager. For a description of the Directory Manager, refer to Directory Manager.
- Helm Charts
From
artifacts.software-univention.de
:udm-rest-api
- Images
From
artifacts.software-univention.de
:udm-rest-api
- Pods
udm-rest-api
The pod realizes the UDM HTTP REST API application component that makes up the Directory Manager functional component.
See also
- Directory Manager in interfaces and protocols section
for information about incoming and outgoing interfaces.
- Directory Manager in components section
for information about internal components and behavior.
2.5.4. End User Self Service#
Fig. 2.28 shows the deployment view of the End User Self Service. For a description of the End User Self Service, refer to End User Self Service.
- Helm Charts
From
artifacts.software-univention.de
:self-service-listener
- Images
From
artifacts.software-univention.de
:self-service-invitation
- Pods
self-service-listener
The pod realizes the Self Service Consumer application component from the End User Self Service functional component.
See also
- Identity Provider in interfaces and protocols section
for information about incoming and outgoing interfaces.
- Identity Provider in components section
for information about internal components and behavior.
2.5.5. Identity Provider#
Fig. 2.29 shows the deployment view of the Identity Provider. For a description of the Identity Provider, refer to Identity Provider.
- Helm Charts
From
artifacts.software-univention.de
:keycloak
keycloak-bootstrap
keycloak-extensions
- Images
From
artifacts.software-univention.de
:keycloak-bootstrap
keycloak-handler
keycloak-proxy
From
docker.software-univention.de
:keycloak-keycloak
- Jobs
keycloak-bootstrap
- Pods
keycloak
keycloak-handler
keycloak-proxy
The pods realize the respective application components that ultimately make up the Identity Provider functional component. The Keycloak Handler and the Keycloak Proxy aggregate to the Keycloak Extensions application component.
See also
- Identity Provider in interfaces and protocols section
for information about incoming and outgoing interfaces.
- Identity Provider in components section
for information about internal components and behavior.
2.5.6. Identity Store and Directory Service#
Fig. 2.30 shows the deployment view of the Identity Store and Directory Service. For a description of the Identity Store and Directory Service, refer to Identity Store and Directory Service.
- Helm Charts
From
artifacts.software-univention.de
:ldap-notifier
ldap-server
- Images
From
artifacts.software-univention.de
:ldap-notifier
ldap-server
- Pods
ldap-notifier
ldap-server-primary
ldap-server-secondary
ldap-server-proxy
The pods realize the respective application components that ultimately make up the Identity Store and Directory Service functional component. Nubus for Kubernetes launches multiple pods for each LDAP Primary, each LDAP Secondary, and each LDAP Proxy.
Fig. 2.31 shows jobs that load data through the UDM HTTP REST API to the LDAP Server.
- Helm Charts
From
artifacts.software-univention.de
:stack-data-ums
stack-data-swp
- Images
From
artifacts.software-univention.de
:data-loader
- Jobs
stack-data-ums
stack-data-swp
See also
- Identity Store and Directory Service in interfaces and protocols section
for information about incoming and outgoing interfaces.
- Identity Store and Directory Service in components section
for information about internal components and behavior.
2.5.7. Management UI#
Fig. 2.32 shows the deployment view of the Management UI. For a description of the Management UI, refer to Management UI.
- Helm Charts
From
artifacts.software-univention.de
:umc-gateway
umc-server
- Images
From
artifacts.software-univention.de
:umc-gateway
umc-server
From
docker.io
:memcached
- Pods
umc-gateway
umc-server
umc-server-memcached
The pods realize the respective application components that ultimately make up the Management UI functional component.
2.5.8. Portal Service#
Fig. 2.33 shows the deployment view of the Portal Service. For a description of the Portal Service, refer to Portal Service.
- Helm Charts
From
artifacts.software-univention.de
:notifications-api
portal-server
portal-frontend
portal-listener
- Images
From
artifacts.software-univention.de
:notifications-api
portal-server
portal-frontend
portal-listener
- Pods
notifications-api
portal-server
portal-listener
The pods realize the respective application components that ultimately make up the Portal Service functional component.
2.5.9. Provisioning Service#
Fig. 2.34 shows the deployment view of the Provisioning Service. For a description of the Provisioning Service, refer to Provisioning Service.
- Helm Charts
From
artifacts.software-univention.de
:udm-listener
provisioning
- Images
From
artifacts.software-univention.de
:provisioning-events-and-consumer-api
provisioning-dispatcher
provisioning-udm-listener
provisioning-prefill
wait-for-dependency
provisioning-udm-transformer
From
docker.io
:nats
nats-server-config-reloader
nats-box
- Jobs
provisioning-register-consumers
- Pods
provisioning-api
provisioning-dispatcher
provisioning-listener
provisioning-prefill
provisioning-udm-transformer
provisioning-nats
The pods realize the respective application components that ultimately up the Povisioning Service functional component.
2.5.10. Ingress configuration#
Fig. 2.35 visualizes the Ingress configuration in Nubus for Kubernetes. Ingress exposes HTTP and HTTPS routes from outside the Kubernetes cluster to services within the cluster. It doesn’t cover other protocols, such as LDAP.
In the default configuration, Nubus for Kubernetes uses the following subdomains:
id.global.domain
subdomain used by the Transparent Proxy to Keycloak.portal.global.domain
subdomain used by all other Ingress configurations.
global.domain
refers to the domain setting in the deployment file for Nubus in your
Kubernetes cluster.
The Ingress configurations in Nubus for Kubernetes determine where Kubernetes routes the traffic for which URL path. For the details of those routes, consult the Nubus Ingress configuration in your cluster.
See also
- Ingress | Kubernetes
for information about the Kubernetes Ingress objects.
global.domain
for information about this setting, see Univention Nubus for Kubernetes - Operation Manual [1].
2.5.11. SQL database: PostgreSQL#
Important
This section is only for your information and applies for Nubus for Kubernetes environments that use the PostgreSQL deployment provided by the Nubus Helm Chart as described in Deploy dependencies based on examples included in Nubus in Univention Nubus for Kubernetes - Operation Manual [1].
This setup is only for testing purposes.
⚠️ Univention doesn’t provide support for the PostgreSQL deployment within Nubus.
For a production deployment and more information, see Use external PostgreSQL database in Univention Nubus for Kubernetes - Operation Manual [1].
Fig. 2.36 shows the deployment view for SQL Database: PostgreSQL.
- Helm Charts
From
docker.io
:postgresql
- Images
From
docker.io
:postgresql
- Pods
postgresql
The pod runs a PostgreSQL database management system. For each application that uses PostgreSQL, the deployment setup creates corresponding databases with corresponding database users and credentials. The figure shows, which application component uses which database, and that the application components access the database management system through the TCP to SQL database interface.
The figure primarily uses structural relationships to show the structure and what goes where. The Serving dependency relationship shows the direct dependencies between the application components and the databases. Table 2.1 shows the direct mappings between databases and application components.
Database |
Application component |
Functional component |
---|---|---|
PostgreSQL DB: Notifications API |
Notifications API |
Portal Service |
PostgreSQL DB: UMC Server |
UMC Server |
Management UI |
PostgreSQL DB: Keycloak |
Keycloak |
Identity Provider |
PostgreSQL DB: Keycloak Extensions |
Keycloak Extensions |
Identity Provider |
PostgreSQL DB: Guardian Management REST API |
Guardian Management REST API |
Authorization Service |