Appendix 1: Creating the Cloud SQL instance and the two databases

Find here the instructions for creating the Cloud SQL Instance with PostgreSQL 13.X and the two databases necessary: keycloak and vectice

We’ll then input the instance name, the master user, and password.

Then, create the two databases, vectice and keycloak, from the menu “Databases,” CREATE DATABASE, create Vectice, and then redo the operation for keycloak.

Appendix 2: Create Bucket and Service account

Find the instructions for creating the role, the service account, and the GCS Bucket.

The role will be attached to the service account to obtain permission to read/write the GCS Bucket. The Bucket is used for storing asset metadata from Models, Datasets, Notes, and Graphs.

Bucket creation

  1. Type Cloud Storage in the search bar and view the first page.

  2. Go to Cloud Storage, Buckets menu, and Press CREATE.

  3. Fill in the settings as in the screenshot below.

IAM role creation

  1. Type IAM in the search enginer.

  2. Create an IAM role with the following permissions:

In this example, it will be named “bucket-storage”.

Service account creation

Assign the IAM role previously created to the service account.

Appendix 3: Creating the Kubernetes cluster

Cluster creation

Type Kubernetes Engine in the search bar and reach the first page. Then click on the CREATE button.

Follow the steps in the console, like in the screenshots below.

Once you select the create button, the cluster creation will take about 30 minutes to build the Cluster, Control Plan, NodePool, and Nodes.

Appendix 4: Disaster recovery plan

Learn more about our data storage and backup policies.

Backup strategy

As there is no persistent data on the Kubernetes Cluster, no backup of the Cluster is necessary. At the minimum, we recommend a daily Backup of the GCS Bucket and the Cloud SQL instance.

The default Cloud SQL instance backup strategy is a daily backup of the whole instance. Backups can also be customized. More information can be found in this GCP documentation. For the Bucket, we recommend making a copy of the Bucket content and placing it in another Bucket, in a folder named with a timestamp to create at each backup.

Recovery mechanism

Depending on the nature of the disaster, recovery solutions might change. In case of an infrastructure issue, please refer to the section; Provisioning the infrastructure to recreate the defaulting infrastructure elements. The restoration of Bucket content consists of copying the content of the time-stamped folder described in the Backup strategy section to the application GCS Bucket on which the helm vectice configuration aims at. The restoration of the Cloud SQL instance consists of restoring the database backup following the GCP documentation. If the issue requires the creation of a new Kubernetes Cluster, for example, in a new region, please refer to the section: Application deployment to redeploy the software. Make sure to fill in the values according to your new environment deployment.

Last updated