Appendices
Last updated
Last updated
Here we have the instructions for creating the Cloud SQL Instance with PostgreSQL 13.X and the two databases necessary: keycloak and vectice.
First, go the menu “Azure Database for PostgreSQL flexible servers” and Press “Create”.
You can then choose the resource group, which will also include the AKS Cluster and the Storage Account. Choose PostgreSQL 13. Then select Press Next: Networking >.
We can use Private Access for the Networking part, as it’s more secure.
We’ll have a dedicated VNet for the PostgreSQL instance that will be created along with the instance. It will also create a dedicated Private DNS zone. For the pods to communicate with the SQL instance, we’ll perform two more actions:
Create a Peering between the AKS VNet and the PostgreSQL VNet
Create a Virtual Network Link from the Private DNS Zone to the AKS VNet
You can select the button “Review + Create” and create the SQL Instance.
Then create the two databases (vectice and keycloak) from the menu “Databases”, CREATE DATABASE, create vectice, then redo the operation for keycloak
Follow the steps in the console, like in the screenshots below.
Here are the instructions for creating the storage account, the container blob storage, and the service principals to get access to the container. The service principals will have permission to read/write the container blob storage. The Bucket is used for storing asset metadata from Models, Datasets, Notes, and Graphs.
First, create a storage account. Go to the “Storage accounts” menu and press Create.
Then fill in the fields and make sure to set it in the same resource group as the AKS Cluster and the Azure PostgreSQL instance in the same Region.
In the Networking part, we select the AKS VNet, so that the content of the storage account can be accessed from the AKS Cluster.
Create the container within the storage account:
First, create a Service Principal. To do so, go to “Azure Active Directory”, then the “App registration” menu, and press “New registration”:
Then, name the Service Principal and Register it.
After that, create a secret for the Service Principal:
We then retrieve the value of the secret now, because after that, the content of the value will not be visible.
Retrieve the values of the Application (client) ID and Directory (tenant) ID. Come back to the storage account previously created, in order to grant the Service Principal access to the Container.
Go to the Access Control (IAM) menu, and in the “Role assignment” tab, Click on Add, Add role assignment.
Set the role “Storage Blob Data Contributor”, and click on Next to define the members:
Select the Service Principal created earlier:
Review and assign the role.
Follow the steps in the console, like in the screenshots below.
Once you push the create button, the creation of Cluster, Control Plan, NodePool, and Nodes will take about 30 minutes.
On the Private DNS Zone created along with the SQL instance, go to the “Virtual network links” menu, and press Add:
Add the link between the Private DNS Zone and the AKS VNet, and enable auto-registration:
Create the VNet Peering between the PostgreSQL VNet and the AKS VNet. To do so, go to the “Virtual Networks” menu and Click on the AKS VNet
Then go to the Peerings menu, and Press Add.
Proceed to the peering of the 2 VNets:
Learn more about our data storage and backup policies.
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 Azure Blob Storage Container 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 Azure documentation.
For the Azure Blob Storage Container, we recommend making a copy of the Azure Blob Storage Container content and placing it in another Azure Blob Storage Container in a folder named with a timestamp to create at each backup.
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 Azure Blob Storage Container on which the helm vectice configuration aims at. The restoration of the Cloud SQL instance consists of restoring the database backup following the Azure 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.
