Solana Client Software Distribution

[kespinola]

ABK Labs Software Distribution Proposal

Introduction

Supporting heterogeneous software deployments is difficult to do efficiently. Different customers require different deployment strategies:

• On-premises bare metal deployments for maximum performance.
• Virtual machine deployments for traditional cloud compute usage.
• Containers for development environments (e.g. docker-compose) or container clusters (e.g. Kubernetes deployments).

One of the best implementation outcomes is when one codebase is capable of automatically generating all of the above assets required for these different strategies. This allows for a small team to move quickly.

Without automation this can be a labor intensive process, fraught with potential for mistakes.

Build/Deployment Process

When tagging a release, or as part of a "nightly" build, build as part of a pipeline:

1. Build software as deb packages; sign and post packages to abk's staging apt repository.

   • Trusted machines (e.g. on-premises, or cloud)
   • Multiple architectures (e.g. x86_64, aarch64)

2. Build customer-facing consumable resources:

   • Bare metal install images.
   • Cloud images (e.g. AWS AMI).
   • Docker/OCI Container Images

3. Automated cluster bring-up:

   • Test out baremetal install inside VM environment (e.g. installing into qemu).
   • Deploy a cloud cluster (e.g. terraform/pulumi deploy AWS ECU instances inside a VPC).
   • Deploy containers into cluster (e.g. Kubernetes).

4. Each cluster put under smoke/functional testing.

   • Quickly validate that the software works as expected.
   • Depending on changes, run longer-running automated tests.

5. If tests pass, publish generated assets to the necessary locations.

Implementation Details

Implementing this depends on some basic infrastructure for ABK Labs:

• Repository tooling for building deb packages.
• Package signing keys.
• apt repositories for different builds (e.g. staging vs. tagged release).
  • Public-facing TLS keys used for transport over HTTPS.
  • These repositories can be public, private (e.g. with SSL client cert validation), or a combination.
• Build infrastructure:
  • Continuous Integration (e.g. buildbot).

All of the above build can be done on either controlled bare metal, or cloud instances.

[kespinola]

We have converted this proposal into issues and are actively working toward this specification.