docs: mi/3607/deployment-example

[hajjimo]

Addresses issues #3332 and #3607

Required

• Used LinkOut component on external links
• Reviewed Vale errors and made changes where appropriate
• Ran Prettier
• Previewed updates in Netlify
• Received SME and/or peer approval if updates are significant
• Included a "fixes #" comment

Conditional

• Ensured sequence diagrams follow our style guide
• Included code samples where appropriate
• Updated related READMEs

[netlify]

✅ Deploy Preview for brilliant-pasca-3e80ec ready!

Name	Link
🔨 Latest commit	76c60e7
🔍 Latest deploy log	https://app.netlify.com/projects/brilliant-pasca-3e80ec/deploys/69442d3ff83e5c0008236430
😎 Deploy Preview	https://deploy-preview-3780--brilliant-pasca-3e80ec.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

🚀 Performance Test Results

Test Configuration:

• VUs: 4
• Duration: 1m0s

Test Metrics:

• Requests/s: 40.80
• Iterations/s: 13.62
• Failed Requests: 0.00% (0 of 2454)

📜 Logs

> performance@1.0.0 run-tests:testenv /home/runner/work/rafiki/rafiki/test/performance
> ./scripts/run-tests.sh -e test "-k" "-q" "--vus" "4" "--duration" "1m"

Cloud Nine GraphQL API is up: http://localhost:3101/graphql
Cloud Nine Wallet Address is up: http://localhost:3100/
Happy Life Bank Address is up: http://localhost:4100/
cloud-nine-wallet-test-backend already set
cloud-nine-wallet-test-auth already set
happy-life-bank-test-backend already set
happy-life-bank-test-auth already set
     data_received..................: 886 kB 15 kB/s
     data_sent......................: 1.9 MB 31 kB/s
     http_req_blocked...............: avg=6.66µs   min=2.04µs   med=5.46µs   max=438.99µs p(90)=6.82µs   p(95)=7.68µs  
     http_req_connecting............: avg=500ns    min=0s       med=0s       max=388.85µs p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=97.33ms  min=6.56ms   med=81.43ms  max=550.92ms p(90)=167.22ms p(95)=189.82ms
       { expected_response:true }...: avg=97.33ms  min=6.56ms   med=81.43ms  max=550.92ms p(90)=167.22ms p(95)=189.82ms
     http_req_failed................: 0.00%  ✓ 0        ✗ 2454
     http_req_receiving.............: avg=97.07µs  min=28.1µs   med=82.1µs   max=3.1ms    p(90)=128.96µs p(95)=167.59µs
     http_req_sending...............: avg=37.13µs  min=9.04µs   med=28.63µs  max=952.95µs p(90)=44.42µs  p(95)=61.81µs 
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=97.2ms   min=6.43ms   med=81.24ms  max=550.83ms p(90)=167.14ms p(95)=189.73ms
     http_reqs......................: 2454   40.80106/s
     iteration_duration.............: avg=293.38ms min=190.73ms med=277.01ms max=1.08s    p(90)=361.97ms p(95)=405.76ms
     iterations.....................: 819    13.61698/s
     vus............................: 4      min=4      max=4 
     vus_max........................: 4      min=4      max=4 

[melissahenderson]

Minor comments, but I think you're basically ready for tech review.

[hajjimo]

Removing PR from draft mode for tech review.

This is a guide for an example Helm-Kubernetes deployment that stands up an instance of the Test Wallet as ASE A and an instance of the Interledger wallet app as ASE B and then peers their Rafiki instances together to facilitate Interledger payments among their users.

Direct link to landing page in preview:
https://deploy-preview-3780--brilliant-pasca-3e80ec.netlify.app/integration/deployment/helm-k8s/getting-started/

Navigation:
Deploy Rafiki

• Helm & Kubernetes
  • Get Started
  • Peered Rafiki Instances Example
  • Deploy ASE A
  • Deploy ASE B
  • Peer the ASEs

[bosbaber]

I’m concerned that, given the current state of our actual ASE applications like InterledgerApp and the TestNet Wallet, it is effectively impossible for integrators to set them up and meaningfully interface with them.

As an integrator, I would like to not only set up a Rafiki instance on my own cluster, but also be able to easily set up an ASE. Better yet, I would like to spin up an entire network of ASEs and peer them together in order to experiment. This could be to test multi-hop scenarios, or to evaluate security and performance characteristics.

Unfortunately, the current configurations for InterledgerApp and TestNet Wallet are not only extremely complicated, but as far as I’m aware both have hard dependencies on GateHub, with InterledgerApp depending on several other providers as well. This places an unreasonable expectation on a potential integrator to first create GateHub accounts and then spend most of their time wrestling with a specific ASE, when the original goal was simply to evaluate Rafiki and the Interledger protocol.

To make matters worse, the Docker images for InterledgerApp are not publicly available, and the source code is still closed. Given the other pressures we have, I’m not convinced this will become a priority to change any time this year.

To address this, I propose that we refactor the relevant pipelines to produce CloudNine-like MockASE Docker images, and that we release a formal Helm chart for them. For clarification, I'm referring to the mock-account-servicing-entity application currently used for development in the Rafiki repository. We can then adapt the integration guide to use MockASEs only. This would allow integrators to easily spin up multiple Rafiki nodes, each with its own ASE and set of UIs, and configure peering however they like.

This will require some development effort, and the Helm chart still needs to be created. But honestly, I think this is the only way we end up with an integration guide that is actually worth something.

Once the ASE problem is solved, we can improve the guide to go deeper into security, performance, and other operational topics. But without a steering wheel, the car is going nowhere.

[mkurapov]

@bosbaber

Definitely agree regarding the challenge for ASEs to get up and going with Rafiki.

In general, I imagine the workflow for a dev from an integrating ASE looks like:

1. Spin up the Rafiki local playground (just to interact with the APIs up close)
2. Spin up the Rafiki local playground and add an integration server that connects to their own (ASE) local environment.
3. Spin up one instance of Rafiki in their deployed dev/staging cluster together with their Rafiki integration server.

From here on, their only real option currently is to peer with the deployed test wallet to try sending payments between each other. Manually testing sending transactions from the ASE to test wallet is relatively simple, but sending from the test wallet to the ASE requires them to sign up for an account on the test wallet (fake KYC, etc), and click through transaction sending, which isn't smooth.

Having a simple mock ASE that the integrator deploys themselves would definitely be a welcome addition to try out Rafiki & ILP. It does still feels a bit cumbersome, since each ASE (mock or not) requires deploying a host of Rafiki services + the associated infrastructure.

Since the current test wallet is very much an end-user, and "Open Payments developer"-focused example of an ASE. it seems we are missing a "Rafiki integrator/developer"-focused example. Maybe what we need is to update the current mock ASE we have (to view & manage more things like peers, payment scenarios, logs), and deploying that ourselves. Then, we could point Rafiki integrators to use that instead of the user-facing test wallet. We could even have a simple login screen that essentially "namespaces" all of the resources that this Rafiki integrator creates as a result of their testing/experimenting.

In any case, this requires a larger conversation for sure :)

As far as the docs go, in my opinion. the particular "Deploy Rafiki > Helm & Kubernetes" page should consist of how to deploy the Rafiki services only. The other testing configurations that concern things like mock ASEs + multiple nodes should live in "Integration > Testing" or similar.

[mkurapov]

@hajjimo what are your thoughts re:

As far as the docs go, in my opinion. the particular "Deploy Rafiki > Helm & Kubernetes" page should consist of how to deploy the Rafiki services only. The other testing configurations that concern things like mock ASEs + multiple nodes should live in "Integration > Testing" or similar.

?

[hajjimo]

@hajjimo what are your thoughts re:

As far as the docs go, in my opinion. the particular "Deploy Rafiki > Helm & Kubernetes" page should consist of how to deploy the Rafiki services only. The other testing configurations that concern things like mock ASEs + multiple nodes should live in "Integration > Testing" or similar.

?

Right now the "Get Started" page of this set is under Deploy Rafiki > Helm & Kubernetes on the live site. We can keep that there, and then depending on how we land on the integrator journey and if we provide a Rafiki integration server , we can consolidate, reorient or entirely revamp the Testing section. But yes, I agree the new material is logically more suited under Integration > Testing.