Registry administrators onboarding

This page is intended for educating registry administrators and provides a comprehensive description of their role, responsibilities, and requirements related to managing, supporting, and monitoring the registry and its components. The educational material covers a wide range of aspects related to working with the registry and the skills necessary for effectively performing administrator duties.

Specific features of working with the registry regulations are described, defining its operational logic, including data models, business processes, and user interfaces.

Furthermore, a detailed overview of the centralized administrative interface for managing registries is provided — the Control Plane admin panel. The process of creating registry administrators with necessary access rights is explained.

Educational material also highlights user management and registry access through the authentication and authorization tool known as Keycloak.

The course covers topics such as authentication processes for end-users, backup and restoring of registry components, including databases, using automated processes in Jenkins.

The process of updating registry components, managing service resources, integration with other registries and external systems through REST and SOAP APIs is explained.

The course imparts knowledge about configuring keys and digital signature certificates for the registry, configuring domain names for registry web portals and the Keycloak service.

It also explains how to restrict access to registry components using CIDR, approve or reject registry change requests (Merge Requests).

The course also includes administering business processes using Camunda BPM, configuring and using VCS git and Gerrit, as well as managing configurations and access limits (rate limits) to internal resources using the Kong API gateway.

Additionally, the educational material discusses configuring a mail server for message exchange within the registry. Thus, after completing the course, you will gain a thorough understanding of registry administration aspects and the necessary skills for fulfilling this role.

Responsibilities and requirements for a registry administrator encompass servicing, supporting, and monitoring the registry and its components.

The Platform administrator creates a registry and adds the initial administrator for that registry. Subsequently, such a registry administrator creates other administrators.

These administrators have the ability to work with the registry, including editing settings by making changes to the registry configuration.

Deployment and updating of registry configurations occur through the GitOps approach.

The core registry configurations are stored in the deploy-templates/values.yaml file of the control-plane-gerrit component within your registry’s Gerrit repository. The Gerrit repository serves as a code review system built on the git VCS.

Part of the configurations is also stored in files such as:

The deployment of registry configurations is managed by the control-plane-jenkins component, specifically through an automated Jenkins process (also referred to as a job) MASTER-Build-<registry-name>, where <registry-name> is the name of the registry. This process is triggered by the event of a git merge of changes into the master branch of your registry’s repository within the central Gerrit component of the Platform.

Actual configurations are applied to the registry through the convenient interface of the Control Plane component—the administrative control panel for the Platform and registries (for more details, refer to Managing registries in the Control Plane admin panel).

The Control Plane admin panel is the central interface, a starting point for registry administrators that provides full access to necessary services for efficient administrative functions. Through it, you control resources, configurations, and tools necessary for comprehensive registry management, and easily transition to other important Platform services.

Control Plane enables management of two types of components deployed on the Platform:

The registry administrator has access to the Registries tab and can edit registry settings and its components (regulations - registry-regulations).

Main registry settings are stored in the deploy-templates/values.yaml file of the control-plane-gerrit component within your registry’s Gerrit repository. The Gerrit repository serves as a code review system built on the git VCS.

Part of the configurations is also stored in files such as:

All Platform users are created in the user-management project, in the user and access management service Keycloak. They are created in different realms^[1] based on their permissions. The principle of least privilege is followed when granting access on the Platform.

Three main types of users can be distinguished within the registry:

It makes sense to also define separately the fourth type — system users used for "system-to-system" interactions in external API integrations.

Several main realms are designated for storing registry users in Keycloak:

The full realm name consists of your registry’s name and the corresponding suffix. For example, <registry-name>-officer-portal.

After the successful deployment of the registry and its regulations, the administrator has the ability to create a backup of the registry. The backup process on the Platform is managed by the Velero mechanism, which stores backups in a secure object storage called Minio.

The automated Jenkins process, Create-registry-backup, is responsible for creating backups of the registry components. To restore the registry from a created backup, the Jenkins process, Restore-registry, can be utilized.

Additionally, the system replicates certain business process data stored as ObjectBucketClaim (obc) in S3 buckets. The replication of these buckets occurs automatically through the automatic copying of data from one bucket to another. This can be valuable, for instance, to create backups in different geographical regions, ensuring high availability and reliability. You can configure backup settings for these replications through the Control Plane administrative panel.

Furthermore, the Platform includes a separate mechanism for backing up and restoring the operational database cluster of the registry using the pgBackRest tool.

Registry updates are managed using the GitOps approach. This means that any changes to the registry configuration or its components are made by modifying the configuration in the respective component’s git branch. Each component is maintained as a separate git repository.

The management of registry component updates takes place in the Control Plane's administrative panel for cluster and registry management.

Specific considerations must be taken into account when updating the registry to a particular version. These require special steps to ensure successful updates.

The registry administrator can employ the Kibana tool as part of the EFK stack (Elasticsearch, Fluentd, Kibana) for event logging within the system. The EFK stack handles the collection, processing, and visualization of event logs, promoting transparency and system monitoring.

The event logging subsystem is deployed in a separate project within OpenShift named openshift-logging. This isolation separates logging-related resources from other system components, enhancing security and stability.

Kibana is utilized for visualizing the logs of all applications on the Platform, offering an interactive interface for log analysis and event tracking. Through Kibana, users can easily identify and resolve issues, as well as obtain crucial performance metrics about the platform’s services and registries.

Monitoring general performance metrics is available to the technical registry administrator through the Grafana web interface. This functionality enables administrators and developers to easily track key metrics related to business processes, using the information to timely identify and address issues and enhance system productivity.

The registry’s business process administrator employs the Business Process Administration Portal, also known as Camunda Cockpit, for managing business processes.

Camunda Cockpit serves as a robust tool for controlling and monitoring business processes on the Camunda BPM platform, helping administrators and users efficiently manage processes for optimal productivity.

Registry administrators and regulation developers have the capability to configure the handling of geodata^[2] within the framework of business processes, thanks to the GIS^[3] (Geographic Information System) module, which has been implemented into the system.

The GIS module is deployed automatically alongside the registry from the geo-server template.

Administrators must comprehend the specifics of working with registry regulations. The regulations consists of entities that define the logic of registry operation, including data models, business processes, UI input forms, and more.

Depending on the requirements of the target registry, the role of the regulations administrator can either be integrated into the duties of the registry administrator or stand distinctly. Regardless, a separate course has been developed for working with regulations within a specific registry.

Regulation deployment is automated through the MASTER-Build-registry-regulations process. It is triggered automatically by the Jenkins service following changes to the master branch of the Gerrit repository with the regulations.

To minimize the risks of human error and provide an additional validation mechanism for modeling accuracy, an automatic validation of changes is conducted during regulations deployment.

Lastly, the Platform allows the deletion or partial cleaning of your registry’s regulations. This is accomplished through the Cleanup process (cleanup-job) in Jenkins—an automated process designed to maintain optimal registry regulation health by removing outdated or unnecessary data, resources, and components. The process involves cleaning temporary database replicas, resources, services, and the Nexus repository. Additionally, it offers the ability to choose extra options based on the administrator’s needs.

The registry administrator can employ the demo registry as a standard reference for working with digital regulations.

The demo registry’s regulations encompass reference examples marked with the prefix reference- and test examples marked with the prefix feature-. These can be exemplars of .bpmn schemas for business processes, .json forms for data input into processes, .xml schemas for deploying registry data models, and more.

If such a registry is already deployed, you can inquire about gaining access.

The registry administrator must understand the intricacies of user authentication on the Platform. Specific strategies for processing and comparing access attributes are employed for authentication, including:

User authentication in the registry can be managed through the Control Plane administrative panel interface, as described in Configuring user authentication section of this document.