Build a Catalog of Operators using Operator-Registry
What is Operator-Registry?
Operator Registry provides the following binaries:
opm, which generates and updates registry databases as well as the index images that encapsulate them.
initializer, which takes as an input a directory of operator manifests and outputs a sqlite database containing the same data for querying.
registry-server, which takes a sqlite database loaded with manifests, and exposes a gRPC interface to it.
configmap-server, which takes a kubeconfig and a configmap reference, and parses the configmap into the sqlite database before exposing it via the same interface as
pkg/client- providing a high-level client interface for the gRPC api.
pkg/api- providing low-level client libraries for the gRPC interface exposed by
pkg/registry- providing basic registry types like Packages, Channels, and Bundles.
pkg/sqlite- providing interfaces for building sqlite manifest databases from
ConfigMaps or directories, and for querying an existing sqlite database.
pkg/lib- providing external interfaces for interacting with this project as an api that defines a set of standards for operator bundles and indexes.
pkg/containertools- providing an interface to interact with and shell out to common container tooling binaries (if installed on the environment)
Why do I want Operator Registry?
Operator registry allows you to package your operator in a defined format and make it available for OLM so that it can install your operator in a kubernetes cluster.
You can find all the releases of operator-registry in the github release page
- Clone the operator registry repository:
$ git clone https://github.com/operator-framework/operator-registry
- Build the binaries using this command:
$ make all
This generates the required binaries that can be used to package your operator
Test your Catalog locally
Make your operator available for OLM in a cluster