soroban rpc deployment manifest

[sreuland]

What

added a reference manifest to deploy soroban rpc to a k8s cluster. This manifest uses quickstart dockerhub image for the soroban-rpc runtime as a first iteration of deployment.

Why

provide a running instance of soroban rpc on futurenet, for convenience to explore and test with as a reference example, this instance is meant for learning/discovery, not meant to be used for real/prod scenarios.

Closes #418

Known limitations

this relies on quickstart image reference for soroban-rpc runtime, is meant as first iteration, longer term k8s deployments should use a dedicated deployment image for rpc

[2opremio]

Shouldn’t we just use https://github.com/stellar/helm-charts/tree/main/charts/soroban-rpc ?

[sreuland]

Shouldn’t we just use https://github.com/stellar/helm-charts/tree/main/charts/soroban-rpc ?

this manifest was done to provide stop gap deployment now using quickstart image which has the captive core config for latest rpc version wired up.

the helm chart is using older image/verrsion of rpc, doesn't have captive core yet. The next step #382, it will shore up this rpc deployment, updating it's dockerfile for multi-stage, build, and runtime with captive core, and pushing as a dockerhub image, then use that from the helm.

[jacekn]

the helm chart is using older image/verrsion of rpc, doesn't have captive core yet. The next step #382, it will shore up this rpc deployment, updating it's dockerfile for multi-stage, build, and runtime with captive core, and pushing as a dockerhub image, then use that from the helm.

I updated the linked issue but maybe we should aim to not have captivecore built into the image? Docker best practice is one process per container and bundling captive core with soroban-rpc goes against that. Maybe the design should be discussed a bit more before we commit to it?

[sreuland]

the helm chart is using older image/verrsion of rpc, doesn't have captive core yet. The next step #382, it will shore up this rpc deployment, updating it's dockerfile for multi-stage, build, and runtime with captive core, and pushing as a dockerhub image, then use that from the helm.

I updated the linked issue but maybe we should aim to not have captivecore built into the image? Docker best practice is one process per container and bundling captive core with soroban-rpc goes against that. Maybe the design should be discussed a bit more before we commit to it?

Yes, see your comment on #382, we can continue that design discussion as part of scope on that effort, sounds good, I think is one reason why have taken the approach here with standalone manifest referring to existing known working config in quickstart/rpc to enable rapid initial deployment in short term, but with acknowledgement that #382 is needed as follow-on iteration for formalized single-purpose(rpc) deployment.

[sreuland]

@mollykarcher , this is effectively done, this k8s manifest has been used to provide the short term deployment on k8s cluster, I don't think it's worth merging this as the manifest is only for short term usage to support ops, can refer to the file here on pr as needed, I will close the pr for completeness.