Launchpad Namespaces

Introduction

Launchpad Namespaces, part of the Launchpad Toolkit, leverages Helmfile to offer a declarative way for deploying and managing functionally related bundles of helm charts (called releases in helmfile).

It aims to:

• be easy to use, while extensible and adaptable
• provide sensible working defaults that can always be overridden
• service the requirements of Launchpad and GraphOps

Features

• Actively maintained by GraphOps and contributors
• Common values interfaces across all namespaces
• Flexible and adaptable, allowing defaults to be overridden
• Two release channels: stable and canary
• A large selection of Namespaces (listed below)

Getting Started

Note Launchpad Starter is a great way to make use of Namespaces and worth checking out as a starting point for every new Launchpad deployment.

To use Namespaces you will require both a Kubernetes cluster and Helmfile. As such:

• Make sure your Kubernetes Cluster is in order and your environment has the kubeconfig context adequately setup
• Install helmfile, upstream guidance available here: Helmfile Installation – Install kustomize, upstream guidance available here: Kustomize Installation. Although launchpad–namespaces doesn't explicitly use kustomize, it is a dependency for utilising helmfile features.

Next, setup an helmfile.yaml file that makes use of the Storage Namespace by creating it with the following contents:

helmfiles:
  - path: git::https://github.com/graphops/launchpad-namespaces.git@storage/helmfile.yaml?ref=storage-latest
    selectorsInherited: true

Note On the path to the helmfile, you can use the query string's ref (?ref=storage-latest) to track one of the release streams: stable and canary, pin to a specific version or just track a particular major or minor semantic version. For more on this, check the Updates section

This is a very minimalist helmfile but enough to get it done. Proceed by running helmfile:

helmfile sync -i

After some output, you should be greeted by a prompt like this:

Do you really want to sync? Helmfile will sync all your releases, as shown above.

[y/n]:

Answer 'y' and hopefully the installation will conclude successfully.

overriding namespace and releases' values

To customize the configuration and deployment, you can pass values to override the default helmfile configuration like so:

helmfiles:
  - path: git::https://github.com/graphops/launchpad-namespaces.git@storage/helmfile.yaml?ref=storage-latest
    selectorsInherited: true
    values:
      targetNamespace: "i-choose-my-own-namespace"
      labels:
        awesome.label.key/stuff: "yes"
        awesome.label.key/thing: "kind-of-thing"

where we add some labels to this Namespace releases, and set it to be deployed on cluster namespace different from default.

You can also easily override values for every release, like so:

helmfiles:
  - path: git::https://github.com/graphops/launchpad-namespaces.git@storage/helmfile.yaml?ref=storage-latest
    selectorsInherited: true
    values:
      targetNamespace: "i-choose-my-own-namespace"
      labels:
        awesome.label.key/stuff: "yes"
        awesome.label.key/thing: "kind-of-thing"
      <release-name>:
        - akey: value
          bkey: value

Check out the Namespaces list below for release names, and each chart's folder for its specific values interface.

To use multiple namespaces on the same cluster, just add more items to the helmfiles array like so:

helmfiles:
  - path: git::https://github.com/graphops/launchpad-namespaces.git@storage/helmfile.yaml?ref=storage-latest
    selectorsInherited: true
    values:
      <storage values>
  - path: git::https://github.com/graphops/launchpad-namespaces.git@<other namespace>/helmfile.yaml?ref=<other namespace>-latest
    selectorsInherited: true
    values:
      <other values>

Updates

You can use git ref's as a means to track what release stream you may want, or to pin to any particular major, minor or patch version. Continue reading for examples on how to achieve that.

following latest:

Your ?ref= would look like this, for the storage namespace: ?ref=storage-latest, or alternatively: ?ref=storage-stable/latest. The path for this Namespace, under helmfiles, would then look like:

- path: git::https://github.com/graphops/launchpad-namespaces.git@storage/helmfile.yaml?ref=storage-latest

following a specific major version:

Your ?ref= would look like this, for the storage namespace: ?ref=storage-v1. The path for this Namespace, under helmfiles, would then look like:

- path: git::https://github.com/graphops/launchpad-namespaces.git@storage/helmfile.yaml?ref=storage-v1

following a specific minor version:

Your ?ref= would look like this, for the storage namespace: ?ref=storage-v1.2. The path for this Namespace, under helmfiles, would then look like:

- path: git::https://github.com/graphops/launchpad-namespaces.git@storage/helmfile.yaml?ref=storage-v1.2

pinning to an exact version:

Your ?ref= would look like this, for the storage namespace: ?ref=storage-v1.2.2. The path for this Namespace, under helmfiles, would then look like:

- path: git::https://github.com/graphops/launchpad-namespaces.git@storage/helmfile.yaml?ref=storage-v1.2.2

following the latest canary:

Your ?ref= would look like this, for the storage namespace: ?ref=storage-canary/latest. The path for this Namespace, under helmfiles, would then look like:

- path: git::https://github.com/graphops/launchpad-namespaces.git@storage/helmfile.yaml?ref=storage-canary/latest

We would recommend that you either follow the latest stable releases, or pin to a specific version and use some other means to keep your helmfile.yaml updated regularly. One way to go about that would be to keep it in a git repository on some supported platform, and use a dependency updating bot (like Renovate) to update it or open PRs for achieving that.

Namespaces

The following namespaces are supported:

:arbitrum

This Namespace provides a suitable stack to operate Arbitrum One and Arbitrum Sepolia archive nodes.

• arbitrum-classic
  The old "classic" Arbitrum tech stack.
• arbitrum-nitro
  Nitro is the latest iteration of the Arbitrum technology. It is a fully integrated, complete layer 2 optimistic rollup system, including fraud proofs, the sequencer, the token bridges, advanced calldata compression, and more.
• proxyd-classic
  Proxyd is an EVM-blockchain JSON-RPC router and load balancer developed in Go by Optimism. It is capable of load balancing, automatic failover, intelligent request routing and very basic caching.
• proxyd-nitro
  Proxyd is an EVM-blockchain JSON-RPC router and load balancer developed in Go by Optimism. It is capable of load balancing, automatic failover, intelligent request routing and very basic caching.

:celo

This Namespace provides a suitable stack to operate Celo mainnet archive nodes.

• celo
  Official golang implementation of the Celo blockchain
• proxyd
  Proxyd is an EVM-blockchain JSON-RPC router and load balancer developed in Go by Optimism. It is capable of load balancing, automatic failover, intelligent request routing and very basic caching.

:ethereum

This Namespace provides a suitable stack to operate Ethereum mainnet, göerli, holesky and sepolia archive nodes.

• erigon
  Erigon is an implementation of Ethereum (execution client with light client for consensus layer), on the efficiency frontier.
• lighthouse
  An open-source Ethereum consensus client, written in Rust and maintained by Sigma Prime.
• nimbus
  Nimbus-eth2 is an extremely efficient consensus layer (eth2) client implementation.
• proxyd
  Proxyd is an EVM-blockchain JSON-RPC router and load balancer developed in Go by Optimism. It is capable of load balancing, automatic failover, intelligent request routing and very basic caching.

:gnosis

This Namespace provides a suitable stack to operate Gnosis mainnet archive nodes.

• erigon
  Erigon is an implementation of Ethereum (execution client with light client for consensus layer), on the efficiency frontier.
• proxyd
  Proxyd is an EVM-blockchain JSON-RPC router and load balancer developed in Go by Optimism. It is capable of load balancing, automatic failover, intelligent request routing and very basic caching.

:graph

This Namespace provides the necessary software to run a Graph Node and participate in the Graph Protocol Network

• graph-database
  Manage Raw Kubernetes Resources using Helm
• graph-network-indexer
  Graph protocol indexer components
• graph-node
  Graph Node is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint.
• graph-operator-mnemonic
  Manage Raw Kubernetes Resources using Helm
• graph-toolbox
  Utility kit for interacting and managing the Graph indexer stack.
• subgraph-radio
  Gossip about Subgraphs with other Graph Protocol Indexers

:ingress

This Namespace adds ingress support and certificate management on kubernetes

• cert-manager
  cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates.
• cert-manager-resources
  Manage Raw Kubernetes Resources using Helm
• ingress-nginx
  ingress-nginx is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.

:monitoring

This Namespace adds software for log and metrics collection and visualization, as well as alarmistic.

• kube-prometheus-stack
  Installs the kube-prometheus stack, a collection of Kubernetes manifests, Grafana dashboards, and Prometheus rules
• loki
  Helm chart for Grafana Loki in microservices mode
• node-problem-detector
  This chart installs a node-problem-detector daemonset. This tool aims to make various node problems visible to the upstream layers in cluster management stack.
• promtail
  Promtail is an agent which ships the contents of local logs to a Loki instance

:polygon

This Namespace provides a suitable stack to operate Polygon mainnet and amoy testnet archive nodes.

• erigon
  Erigon is an implementation of Ethereum (execution client with light client for consensus layer), on the efficiency frontier.
• heimdall
  Validator node for Matic Network.
• heimdall-ha-svc
  Manage Raw Kubernetes Resources using Helm
• proxyd
  Proxyd is an EVM-blockchain JSON-RPC router and load balancer developed in Go by Optimism. It is capable of load balancing, automatic failover, intelligent request routing and very basic caching.

:postgres-operator

This Namespace extends your Kubernetes cluster with custom resources for easily creating and managing Postgres databases

• postgres-operator
  The Postgres Operator delivers an easy to run highly-available PostgreSQL clusters on Kubernetes (K8s) powered by Patroni.

:sealed-secrets

This Namespace provides a Kubernetes controller and tool for one-way encrypted Secrets

• sealed-secrets
  Sealed Secrets are 'one-way' encrypted K8s Secrets that can be created by anyone, but can only be decrypted by the controller running in the target cluster recovering the original object.

:storage

This Namespace uses OpenEBS to provide a software defined storage layer suitable for stateful workloads that require low-latency access to the storage.

• openebs
  OpenEBS is the leading open-source example of a category of cloud native storage solutions sometimes called Container Attached Storage.
• openebs-rawfile-localpv
  RawFile Driver Container Storage Interface
• openebs-rawfile-storageclass
  Manage Raw Kubernetes Resources using Helm
• openebs-zfs-localpv
  CSI driver for provisioning Local PVs backed by ZFS and more.
• openebs-zfs-snapclass
  Manage Raw Kubernetes Resources using Helm
• openebs-zfs-storageclass
  Manage Raw Kubernetes Resources using Helm

Contributing

We welcome and appreciate your contributions! Please see the Contributor Guide, Code of Conduct and Security Notes for this repository.

See also

• graphops/launchpad-charts
• graphops/launchpad-starter
• graphops/launchpad-taskfiles