Deploying the Platform to production without registry development tools
🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions. |
This document provides information on the general points and technical design during Platform deployment.
1. General provisions
-
Components involved in the processes of registry development must not be deployed together with a production version of the Platform for state registries.
-
Public routes of components involved in the processes of registry development must not be created together with a production version of the Platform for state registries.
-
Registry template must include a variable to set the current Platform deployment mode.
-
Two deployment modes are supported:
production
anddevelopment
.
2. High-level technical design
The following table lists the components and their routes, which are involved, or need to be changed/created within the realization of functional requirements according to the technical solution design.
Component for regulations development | Production use | Public endpoint |
---|---|---|
|
Not required |
None |
|
Not required |
None |
|
Not required |
None |
|
Not required |
None |
|
Not required |
None |
|
Not required |
None |
|
Not required |
None |
|
Not required |
None |
|
Not required |
None |
|
Required |
None |
|
Not required |
None |
|
Required |
None |
To configure the corresponding modes for the templates, set the mode the following way:
global: deploymentMode: development
In case you need to deploy a registry without a defined Portal (Citizen Portal, for example), add the following parameter:
global: excludePortals: ['citizen']
By default, excludePortals variable is absent, which means the deployment of all Portals.
|
Excluding Citizen Portal from deployment process means the following services must also not be deployed:
-
citizen-portal
-
ddm-notification-service
-
user-service-api
-
user-service-persistence