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
- Actively maintained by
GraphOps and contributors
- Common values interfaces across all namespaces
- Flexible and adaptable, allowing defaults to be overridden
- Two release channels:
stable
andcanary
- A large selection of Namespaces (listed below)
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
andcanary
, 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.
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>
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.
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.
- 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
We welcome and appreciate your contributions! Please see the Contributor Guide, Code of Conduct and Security Notes for this repository.