Appendices

Appendix 1: Creating the parameter group and SQL instance

Here are the instructions for creating the RDS PostgreSQL Instance and the necessary RDS parameters.

Create a parameter group

To force SSL on your SSL instance, you need to use a parameter group where rds_force_ssl=1 and rds.allowed_extensions = unaccent. Type RDS in the search bar and go to the first page. Go into the Parameter group:

Go on mysslparametergroup and search ssl on the parameters search bar. We need to set rds_force_ssl at value 1 instead of 0. To do so, check the box, and click on Edit Parameters.

Set the value to 1. Then perform the same action for rds.allowed_extensions = unaccent.

Apply by clicking on “Save Changes”.

Create an RDS instance

To Create the RDS instance, go to the RDS menu, then press “Create database”.

Assign the parameter group previously created to the SQL instance.

Appendix 2: Create IAM roles for EKS and Bucket

IAM roles for EKS

Two IAM roles are used by AWS in order to manage the EKS Cluster and Cluster Resources:

IAM role for the Bucket

IAM user credentials from the AWS project, which has permission to read/write the S3 Bucket on client Amazon S3. The Bucket stores asset metadata from Models, Datasets, Notes, and Graphs.

Create the S3 bucket. Below, sample values are provided between brackets:

aws s3 mb s3://<vectice-storage-bucket>

1. Create the IAM User:

aws iam create-user \
  --user-name vectice-service-account

2. Attach the Policy to the User:

aws iam attach-user-policy \
  --user-name vectice-service-account \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess

3. Create an Access Key for the User:

aws iam create-access-key \
  --user-name vectice-service-account

Appendix 3: Creating the Kubernetes cluster

Cluster creation

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

The Cluster needs the private Endpoint to connect the nodes that are created after with the node group and the Public Endpoint to connect from an outside computer. The Private endpoint is used to attach the nodes to the Cluster. The Public endpoint is used to reach the Cluster from outside the VPC.

Once you select the Create button, the creation of the Cluster Control Plan will take about 10 minutes.

Node group creation

You will then need to create the Node Group, selecting how many nodes you want and with which machine type. For that, you need to go to your freshly created cluster on the AWS Management Console and Click on the Button “Add node group”.

Appendix 4: Creating the databases from the Kubernetes cluster

We’ll use the image of Postgresql client from this public repository, just changing the namespace from postgresql-client to vectice. The file to deploy will be the one shown below, save it as postgresql-client.yml:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: postgresql-client
  namespace: vectice

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: postgresql-client
  namespace: vectice

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: postgresql-client
  namespace: vectice
roleRef:
  kind: Role
  name: postgresql-client
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount
    name: postgresql-client

---
apiVersion: v1
kind: Pod
metadata:
  name: postgresql-client
  namespace: vectice
  labels:
    app: postgresql-client
  annotations:
    cluster-autoscaler.kubernetes.io/safe-to-evict: "true"    
spec:
  serviceAccountName: postgresql-client
  securityContext:
    runAsNonRoot: true
    supplementalGroups: [ 10001] 
    fsGroup: 10001    
  containers:
    - name: postgresql-client
      image: andreswebs/postgresql-client
      imagePullPolicy: Always
      securityContext:
        runAsUser: 1000      
      stdin: true
      tty: true
      command: ["/bin/sh"]

Apply the content to create the resources we need:

kubectl --context $CONTEXT -n vectice apply -f postgresql-client.yml
kubectl --context $CONTEXT attach --namespace=vectice -ti postgresql-client

Enter the bash inside the postgresql-client pod, we can create the two databases, and check after the list of databases on the instance. Below, sample values are provided between brackets:

psql "host=<yourhost>  user=<master rds user> password=<yourmasterpassword> dbname=postgres"
CREATE DATABASE vectice;
CREATE DATABASE keycloak;
\l

Get out of the pod and delete the resources just created on the cluster:

kubectl --context $CONTEXT -n vectice delete -f postgresql-client.yml

Appendix 5: Disaster recovery plan

Backup strategy

As there is no persistent data on the Kubernetes Cluster, no backup of the Cluster is necessary. We recommend a minimum daily Backup of the S3 Bucket and the RDS instance.

The default RDS instance backup strategy is a daily backup of the whole instance. Backups can also be customized, more information can be found on this AWS 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 default 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 S3 Bucket on which the helm vectice configuration aims at. The restoration of the RDS instance consists of restoring the database backup following the AWS 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. If the issue did not require the creation of a new RDS instance, the subsection Creation of PostgreSQL databases can be ignored.