How to deploy Certify
- Esther SaurÃ
Pre-Requirements
Database Postgres
Create a database for Certify component
It’s not necessary to create the schemas. Certify automatically creates the schemas when it’s launched.
Docker image
To deploy Certify, it’s necessary to get access to the Certify docker image. If you have no access to it, please contact Gataca.
docker pull gatacaid/certify:[VERSION]Deploying Certify
Due to the security is one of our main concerns, these are the rules to secure communications:
Internal communications (internal network) SHOULD be encrypted, but it’s not mandatory.
External communication (public) MUST be encrypted, using an official certificate (avoid Self-Signed certificates). Gataca Wallet rejects all communications not protected by a valid certificate.
Gataca strongly recommends to use SSL for database communications.
Deploying the container
To deploy Gataca Certify, it must be done using the docker image provided in the previous step. There are many ways to deploy the component using docker: docker daemon, docker compose, orchestrator…
However, this documentation shows how to do it using docker directly.
So, to deploy the service, it’s necessary to execute the following command.
docker run -d
--name Gataca-Certify
--env-file certify-conf.lst
-p 443:9090
-v [path-to-certificates]:/certificates
gatacaid/certify:[VERSION]This command launches the container using the following parameters:
Parameter | Description |
|---|---|
-d | Launches the container in background mode. If this parameter is not set up, the terminal instead of exit the process, continue showing the container logs. |
--name | Set up the name of the container in the machine deployed. |
--env-file | Set up the the file to configure all the environment variables used by the container to be configured internally. |
-p | Map the external and internal ports. By default, service is running in the port 9090, so to map the service to a SSL port it could be done as in the example [443:9090]. If the default port is changed in the env-file, this mapping must be changed to link the external port (443) to the internal one. Although, Gataca recommends to deploy the service using a SSL channel (443), it’s possible also to deploy the service without SSL. In that case, port 443 should be changed too. |
-v path-to-certificates | This parameters allows the image to receive files from the host. In this case, Certify use this mechanism to obtain the certificates used in the SSL channel. Although, Gataca recommends to deploy the service using a SSL channel (443), it’s possible also to deploy the service without SSL. In that case, this parameter is not necessary. |
The table above shows the parameters to launch the container through Docker, but also it’s necessary to configure the service internally. To do this, Gataca uses environment variables set up through an environment file (It could also be done in the command shown previously).
Internal configuration
To set up the internal configuration, Certify uses environment variables. These variables could be configured using the Docker command directly or using a configuration file, as in this example.
Configuration file
In this example, it’s named certify-conf.lst (--env-file certify-conf.lst ).
The next section shows the main properties to be configured in the component.
GAT_SERVER_URL=https://certify.gataca.io
GAT_SERVER_SESSION_TIMEOUT=3600000
GAT_DATABASE_HOST=database.gataca.io
GAT_DATABASE_PORT=5432
GAT_DATABASE_NAME=certify
GAT_DATABASE_USER=certify-db-user
GAT_DATABASE_PASS=12345678
GAT_DATABASE_SSLMODE=disable
GAT_TLS_CERTIFICATE=/certificates/fullchain.pem
GAT_TLS_KEY=/certificates/privkey.pem
GAT_APP_DIDS_HOST=https://dids.gataca.io
GAT_APP_GOVERNANCE_HOST=https://governance.gataca.io
GAT_APP_ACCOUNTS_HOST=https://accounts.gataca.io
GAT_APP_CONFIG_KEYS=DB
GAT_APP_EBSI_URL=https://api.preprod.ebsi.eu
GAT_APP_EBSI_ONBOARDINGISSUER=did:ebsi:4jPxcigvfifZyVwym5zjxaKXGJTt7YwFtpg6AXtsR4d5
GAT_APP_USEPLATFORMCATALOG=trueVariable | Description |
|---|---|
| URL of the subdomain where the service is deployed. This value will be used to create the |
| URL of the Gataca Backbone service. The value of this variable must be |
| Server session timeout in milliseconds |
| Database engine URL (Postgres) |
| Database engine port (Postgres) |
| Database name |
| Database user |
| Database user password |
| [Optional] Indicates if the database connection requires SSL or not. By default, the connection must be secured using certificates, but it’s possible to configure without SSL. |
| [Optional] Indicates the certificate used to secure the communications. By default, the service is configured without SSL. If this field exists in the configuration, |
| [Optional] Indicates the certificate key used to secure the communications. By default, the service is configured without SSL. If this field exists in the configuration, |
| URL of the Gataca DID registry service. This service provides a mechanism to resolve and create new DIDs. The value of this variable must be |
| URL of the Gataca Governance service. This service provides data about the catalogs (registries).
The value of this variable must be |
| URL of the Gataca Accounts service. This service provides mechanism to interact with the user device (Push notifications). The value of this variable must be |
| Indicates where the private keys are in the component. Possible values are [DB, FILE]. By default, this property must be |
| [Optional] URL of EBSI to interact with. |
| [Optional] EBSI DID. This property is used to control when an object provides from EBSI (Issuer). |
| [Optional] Indicates if the client wants to use the remote catalog from the Gataca platform, or on the other hand, it wants to use the private catalogs. Default value: Gataca recommends to use |
Once the command to launch the instance is executed, if the configuration has been set correctly, the service must show a screen as this one in the logs:
If this image is not shown, the service notifies what the problem is executing the service.