interledger
Create helm chart for Rafiki
Create the initial Helm chart deployment for deploying Rafiki. Its expected that the helm chart can be used to deploy Rafiki and any dependencies it has
At a minimum we need
- Deployment
- Service for public and admin access
- Service Account/ RBAC
- Dependencies
- Optionally Deploy Postgres
- Optionally Deploy Tigerbeetl
Good examples Emissaryunder charts folder Cockroach
@RishiKumarRay that would be amazing! do you need any guidance from my side or you happy to run with it?
@matdehaast i wanted to know about this service account or RBAC , like i am new to helm , can you give me any reference regarding RBAC , that would make easy to understand and implement.
@RishiKumarRay the service account and RBAC is a way to enforce permissions within the kuberneretes cluster. RBAC is Role based access control. Below I have given two links to an example RBAC and Service Account in helm
Notes:
Complete list of running applications: backend, auth, rates. These three will be included in the main Rafiki chart. They will be configurable with flags so that a deployer can choose to deploy only the ones that they need. We will require one deployment each of tigerbeetle, postgres, and redis as data stores. We will make a standalone tigerbeetle chart. We will use off-the-shelf postgres and redis charts,. The datastore charts will be included as dependencies in the Rafiki chart.
Container special requirements: backend uses the tigerbeetle client, which participates in the tigerbeetle consensus process. This means that it has the same OS-services requirements as tigerbeetle. We intend to narrow down the permissions for both backend and tigerbeetle to only those required, as opposed to running them in privileged mode as part of another issue.
Data store special considerations: tigerbeetle is single-threaded so its performance characteristics a most closely tied to CPU clock speed and disk access speed. The CockroachDB and Vault charts have similar design concerns and will be good examples to follow. Tigerbeetle specifically likes to have 6 replicas spread across 3(?) zones for redundancy (these do not affect scaling).
Scaling, monitoring etc: backend, auth, and rates scale horizontally. Postgres and redis have published charts & designs. Tigerbeetle, see above. As a very rough order of magnitude estimate, we expect that the disk-size requirements for tigerbeetle will be similar to postgres. We do not currently have monitoring hooks in tigerbeetle or backend, auth, and rates. We will include that as a conversation at the summit and expect to be compatible with prometheus, datadog, etc.
