Written by André Gaul and Todd Kaplinger.

Introduction

In the following sections of this article, we are going to guide developers through the process of standing up a Stellar validator node that can join the Stellar Testnet. We will demonstrate the steps to deploy these services to Kubernetes (here: IBM Cloud and Google Cloud) using Helm as well as some basic examples to verify the system syncs successfully with the network. With the strong industry interest in tokens and Stellar, we hope these Helm charts can accelerate your deployments.

Background of Stellar

Stellar is an open-source and decentralized payment network. The protocol supports digital currencies as well as fiat currencies and allows cross-border transactions between any pair of currencies. Stellar is composed of two key services:

Stellar Core: the distributed Stellar network is made up of servers running the Stellar Core software. These servers are maintained by different individuals and entities. Stellar Core maintains a local copy of the ledger and validates transactions which are then applied to the last ledger to form the next one. For reaching global consensus with other nodes Stellar Core runs the Stellar Consensus Protocol (SCP).

the distributed Stellar network is made up of servers running the Stellar Core software. These servers are maintained by different individuals and entities. Stellar Core maintains a local copy of the ledger and validates transactions which are then applied to the last ledger to form the next one. For reaching global consensus with other nodes Stellar Core runs the Stellar Consensus Protocol (SCP). Stellar Horizon: for querying the ledger and interacting with the network Horizon provides a RESTful API. It allows you to submit transactions, check the status of accounts, and subscribe to event streams.

Deployment Options

The Stellar community has been busy creating simple ways to incorporate Stellar Core and Horizon into your own infrastructure. The two most common deployments that we have come across is the Stellar Quickstart Docker image and SatoshiPay’s Docker images and Docker Compose configurations. Whether you are looking to run a local Stellar node for unit testing (Stellar Quickstart is great here) or want to set up a demo or test environment (Docker Compose version from SatoshiPay is great here) there are deployment options that can be deployed in a matter of minutes. However, there was a gap in terms of simplified deployments to production-grade cloud infrastructure. SatoshiPay has been using Kubernetes for its Stellar infrastructure for more than a year and since many of the major cloud providers support Kubernetes, SatoshiPay released its Helm-based Kubernetes infrastructure code as open source and joined forces with IBM to test and improve the deployment on other clouds as well:

The examples in this article have been tested with a Kubernetes cluster in the IBM Cloud. The same Helm charts power SatoshiPay’s full validator nodes in the Google Cloud.

Why Helm?

Helm is kind of a package manager for Kubernetes deployments. A package is called a chart in Helm’s terminology. To get started with using Helm and installing Helm charts, you need to download the Helm CLI and install the cluster-side component Tiller into an existing Kubernetes cluster. For the purpose of this article, we assume you already have an existing Kubernetes cluster to target.

Prepare the Kubernetes cluster

Install Helm

Prior to installing Helm, the cluster needs some basic RBAC security set up. The Helm docs provide more details on RBAC (https://helm.sh/docs/rbac/) but for the sake of simplicity, we will provide a basic service account and cluster role binding to allow the Helm CLI to interact with the target cluster. Once the RBAC is configured, we can download the latest version of Helm and initialize the server component Helm Tiller.

## Set up Helm security

$ kubectl --namespace kube-system create serviceaccount tiller

$ kubectl create clusterrolebinding tiller-cluster-rule \

--clusterrole=cluster-admin \

--serviceaccount=kube-system:tiller $ kubectl --namespace kube-system patch deploy tiller-deploy \

-p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

$ curl -L ## Get helm$ curl -L https://git.io/get_helm.sh | bash ## Initialize Helm (installs Tiller in the cluster)

$ helm init --service-account tiller

Cloud-specific cluster initialization

The cluster you are using might need some initialization that is specific to where and how you run the cluster. A typical task is creating storage classes so disks can be automatically provisioned with the desired properties or setting up ingress controllers for exposing HTTP endpoints. We provide two examples here for storage classes:

Install Stellar Core

Generate a node seed

Stellar Core requires a node seed to be generated for each Stellar Core node. To generate the secret that we will be used as the node seed, simply run this command and provide this seed during the installation of the Stellar Core helm chart later.

$ docker run --rm -it --entrypoint '' \

satoshipay/stellar-core \

stellar-core gen-seed

The output will look like this:

Secret seed: SBH2ZIGO5DHNAPJTDAXA74JARGTHXG3YBY5A3VBXZX44VGHQ6QMWDDI7

Public: GD5PNS22BMZOKUAPELTRUH5E5P4Q4NEZHFRBJ6V6X7HJZSMPTB6GNT3Q

Get Helm charts

In an effort to keep things simple, we are going to jumpstart things by cloning an existing GitHub repo.

In this repo, there is a set of Helm charts and default Testnet values that can be used to drive the deployments for both Stellar Core and Horizon.

Fetch dependencies

Now that you have Helm initialized and RBAC properly configured, we will look to install the core Stellar helm chart. Stellar Core has a dependency on PostgreSQL which is declared in the Helm chart requirements.yaml . Helm will determine the required child charts that need to be deployed and helm install those dependencies prior to installing the parent chart.

The steps to install the Helm chart along with its requirements are:

# Download chart dependency (postgresql)

$ helm repo update

$ helm dependency update stellar-core

Install time

# Use the node seed that you generated

$ NODE_SEED=SBH2ZIGO5DHNAPJTDAXA74JARGTHXG3YBY5A3VBXZX44VGHQ6QMWDDI7 # Install Stellar Core and dependency (postgresql)

$ helm install \

--namespace stellar-testnet \

--name stellar-core \

--set nodeSeed=$NODE_SEED \

--values stellar-core.testnet.values.yaml \

stellar-core

You will notice that in the Helm install command, we specify a values file representing the Testnet configuration. To participate in the Testnet network, Stellar Core needs to know existing known peers that are part of the Testnet, how to participate in the Stellar Consensus Protocol with which quorum slices, and where to retrieve historical Testnet data.

Verify that Stellar Core is synced

The simplest way to verify that your Stellar node is synced is to view the pod logs for Stellar Core. The name of the Stellar core pods are dynamic but have a well-defined prefix based upon the Helm chart name (stellar-core). In our local deployment, we will demonstrate what to look at and the indicators that we have a synced node.

First look to see the active logs (in this example, the pod is stellar-core-5d4db749cb-95zl ):

$ kubectl -n stellar-testnet get pods

NAME READY STATUS RESTARTS AGE

stellar-core-5d4db749cb-95fzl 1/1 Running 4 57m

stellar-core-postgresql-0 1/1 Running 0 56m

Then view the pod’s logs:

$ kubectl -n stellar-testnet logs stellar-core-5d4db749cb-95fzl

Your node is participating in SCP and validating transactions once the validated attribute is true .

2019-05-30T18:47:44.111 GBN6Y [Ledger INFO] Got consensus: [seq=591360, prev=74a7a5, txs=5, ops=78, sv: [ txH: c90a05, ct: 1559242064, upgrades: [ ] ]]

2019-05-30T18:47:44.112 GBN6Y [Tx INFO] applying ledger 591360 (txs:5, ops:78)

2019-05-30T18:47:44.169 GBN6Y [Ledger INFO] Closed ledger: [seq=591360, hash=949c36]

2019-05-30T18:47:50.861 GBN6Y [Herder INFO] Quorum information for 591359 : {"agree":3,"delayed":0,"disagree":0,"fail_at":1,"hash":"1e8826","missing":1,"phase":"EXTERNALIZE","validated":true}

Install Stellar Horizon

Once we have a synced Stellar Core node, we are ready to install the Horizon service. Similar to Stellar Core, Horizon also has a dependency on PostgreSQL. The commands are quite similar in terms of updating the Helm repo and obtaining the Helm chart’s dependency. You will notice in this step, we have again defined a values file that overrides the default settings defined in the Helm Chart. We also provide a collection of overrides using the --set option to configure the Ingress (Ingress is the front door proxy and unique to each cluster). In the values.yaml , we configure the location of the existing Stellar Core installation as well as the PostgreSQL database that Stellar Core uses.

Fetch dependencies

$ helm repo update

$ helm dependency update stellar-horizon

helm install \

--namespace stellar-testnet \

--name stellar-horizon \

--set ingress.enabled=true \

--set ingress.hosts[0].name="stellar-satoshipay.us-south.containers.appdomain.cloud" \

--set ingress.hosts[0].tlsSecret="stellar-satoshipay" \

--set service.port=8000 \

--values stellar-horizon.testnet.values.yaml \

stellar-horizon

Verify that Horizon is ready to handle requests

The Stellar Horizon service leverages Kubernetes probes (liveness and readiness). You can learn more about them in the Kubernetes documentation. For now, we will simply check that the pods are deemed ready. Once we have the Stellar Horizon pod ready, we can scan the logs again to determine if we are ready.

$ kubectl -n stellar-testnet get pods

NAME READY STATUS RESTARTS AGE

stellar-core-5d4db749cb-95fzl 1/1 Running 4 67m

stellar-core-postgresql-0 1/1 Running 0 66m

stellar-horizon-58df4489fd-t6r8z 1/1 Running 3 67m

stellar-horizon-postgresql-0 1/1 Running 0 3h14m

Now check the logs of Horizon with:

$ kubectl -n stellar-testnet logs stellar-horizon-58df4489fd-t6r8z

If ledgers are ingested then the logs will look similar to the following:

time="2019-05-30T19:08:16.458Z" level=info msg="Ingesting ledgers..." first_ledger=591587 last_ledger=591587 pid=1 service=ingest

time="2019-05-30T19:08:16.474Z" level=info msg="Finished ingesting ledgers" duration=0.015715012 first_ledger=591587 last_ledger=591587 pid=1 service=ingest

By this point in time, we are really done with verifying that the system is ready for action. One thing we should mention is that we also have two PostgreSQL databases that are now running. If you see that the databases are not running, you are likely hitting permissions issues with storage or wrong storage classes. We have found that ensuring that Stellar Core is completely started and has synced is an absolute requirement before attempting to do anything with Horizon.

Interact with Horizon

After we have confirmed that we have joined the Stellar network, we can run a simple test with Friendbot to demonstrate that accounts created on the Stellar Testnet can be accessed via our Stellar node. The Stellar Laboratory provides a nice web interface for generating keypairs and funding a test network account.

Once the keypair has been generated and account has been funded with 10,000 lumens, we can now verify that our Stellar Node synchronizes new ledgers that the network produces.

For the purpose of demoing, we can directly access the root URL of Stellar Horizon server (here: http://stellar-satoshipay.us-south.containers.appdomain.cloud/ ). Using the public key that was created with Friendbot, we can now verify the account has been created (here: http://stellar-satoshipay.us-south.containers.appdomain.cloud/accounts/GA344BMFZOU3GSPKGRDQ7UY6TX5GKOFGLBCGEWMDMV62MTAQCFRUD6CA ) and also verify the account balance is 10,000 lumens.

About the authors

André Gaul (@andrenarchy) is a researcher at SatoshiPay and maintains their globally distributed full Stellar validator nodes. He holds a PhD in mathematics and is the CEO of the collaborative research platform PaperHive.

Todd Kaplinger (@todkap) is a deeply skilled innovator with expertise delivering complex cloud software architecture, engineering and development with a strong history of recruiting and building strong technical organizations. With 20 plus years of software engineering experience, he has led development in the fields of Cloud, Mobile, and Web and most recently Digital Tokens using Stellar. He recently joined NCR after spending the previous 18 years at IBM.

References

Extracts of this article were obtained from Wikipedia, the Stellar Development Foundation, and the SatoshiPay blog.