Skip to content

graphops/launchpad-namespaces

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Launchpad Namespaces

License

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 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:

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.

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.

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.
  • 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.

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.
  • lighthouse
    An open-source Ethereum consensus client, written in Rust and maintained by Sigma Prime.
  • 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.

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

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.

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

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.

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.

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.

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

Contributing

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

See also