Deployment Image for Soroban RPC

[sreuland]

What problem does your feature solve?

1. Add multi-arch(linux/amd64 and linux/arm64) support for building the image from cmd/soroban-rpc/Dockerfile.

2. Document the image in cmd/soroban-rpc/docker/README:

• describe current limitation on linux/amd64 builds only
• how to build the image from command line using provided cmd/soroban-rpc/docker/Makefile

  STELLAR_CORE_VERSION="19.10.1-1310.6649f5173.focal~soroban" SOROBAN_RPC_VERSION=0.8.0-21 make docker-build
  

• define the release process for pushing new versions of the image for a soroban release.
  • implement the necessary GH CI workflow to be triggered automatically to build/push image to dockerhub when a GH release is created on soroban-tools.

[sreuland]

@satyamz , when the new docker image is published from this effort, stellar/soroban-rpc, we should update soroban-rpc helm chart to refer to it. Also, soroban rpc runtime config parameters have progressed, there are new settings now for captive core configurations needed. I think can use the latest quickstart environment config for rpc as reference for latest settings to include in helm chart. Noticed the helm chart spins up a core container on futurenet already, so, the captive core config settings would just need to be tailored to point to that instance for peer'ing.

[satyamz]

when the new docker image is published from this effort, stellar/soroban-rpc, we should update soroban-rpc helm chart to refer to it.

You can open a PR for that whenever docker image is ready. Also you would need to update the image tag here

Noticed the helm chart spins up a core container on futurenet already, so, the captive core config settings would just need to be tailored to point to that instance for peer'ing.

Captive core settings needs to be updated on the futurenet horizon which is not included in the soroban-rpc helm chart.

[jacekn]

@sreuland we maintain official core docker images, it could be nicer to reuse them instead. In k8s soroban-rpc Deployment could use 2 containers inside the same pod which is a common pattern. For local development we could recommend minikube or similar

[sreuland]

@sreuland we maintain official core docker images, it could be nicer to reuse them instead. In k8s soroban-rpc Deployment could use 2 containers inside the same pod which is a common pattern. For local development we could recommend minikube or similar

the proposed stellar/soroban-rpc image was intended to be that type of official image, we can setup the gh workflow on this repo to automate the pushing of the image during release/tag event, or are you suggesting a CI server job instead to push images?

[jacekn]

@sreuland we maintain official core docker images, it could be nicer to reuse them instead. In k8s soroban-rpc Deployment could use 2 containers inside the same pod which is a common pattern. For local development we could recommend minikube or similar

the proposed stellar/soroban-rpc image was intended to be that type of official image, we can setup the gh workflow on this repo to automate the pushing of the image during release/tag event, or are you suggesting a CI server job instead to push images?

I am proposing for stellar/soroban-rpc be pure soroban-rpc image with just one binary (and pid) inside. The image could use the existing stellar/stellar-core image, just like we did in the soroban-rpc helm chart.

[sreuland]

I am proposing for stellar/soroban-rpc be pure soroban-rpc image with just one binary (and pid) inside. The image could use the existing stellar/stellar-core image, just like we did in the soroban-rpc helm chart.

ok, yes, the scope of this effort can follow that suggestion for the soroban rpc image, and scope includes updating the helm chart to use it correctly.

The latest rpc version runs captive core, which the helm chart doesn't reflect yet, the rpc image needs to have the core bin in it now and that can be copied into the image during build as multi-stage from existing stellar/stellar-core image.

Part of the design here on rpc image will also need to account for how to provide the captive core config file to rpc service. Could mount a volume having the captive core config file specific to the network desired for connection or we just include a copy of each .cfg for each network available in the rpc image. Quickstart as one reference, it follows the latter approach of maintaining a canned version of the .cfg's for each network in the rpc image it builds stellar/quickstart:soroban-dev

[jacekn]

Currently "release" Dockerfile and Makefile arehere

For example we can build it like this:

STELLAR_CORE_VERSION="19.10.1-1310.6649f5173.focal~soroban" SOROBAN_RPC_VERSION=0.8.0-21 make docker-build

[sreuland]

@tsachiherman , I re-scoped the description on ticket as most of it was obsoleted by recent work already merged by @jacekn - #710

I think the Preview 10 label can be removed from this ticket and reprioritized given its remaining scope.

[sreuland]

The remaining criteria on this ticket is resolved:

• describe current limitation on linux/amd64 builds only - this is implicitly forced in the cmd/soroban-rpc/docker/Makefile

• how to build the image from command line using provided cmd/soroban-rpc/docker/Makefile - the makefile is self documenting, just read it.

• define the release process for pushing new versions of the image for a soroban release - we have Jenkins job stream that can be manually run to build cmd/soroban-rpc/docker/Dockerfile.release and push to

closing the ticket.

[mollykarcher]

thanks @sreuland!