Plugins
Besides just operating on a Capsule CRD, the Rig operator has support for plugins. A Rig plugin is a piece of code running at each reconcile loop of the operator. It has read access to the spec of the Capsule being reconciled and read/write access to the set of resources generated by the operator.
Plugins are a way for the rig administrator to extend the capability of a capsule with custom logic not necessarily captured by the Capsule spec. The intention behind the plugins is to enable custom infrastructure configuration that developers need not know about so their interface with Kubernetes (i.e. the Capsule spec) continues to be simple and understandable in a way the general Kubernetes APIs usually are not.
Which plugins are run for which capsules and their configuration is defined in the Operator Config configured by the Helm values.yaml
file.
Rig supplies a list of builtin plugins you can see here.
Configuring Plugins
Plugin executions are defined as a fixed sequence of plugins and their configuration to be executed. They are grouped into steps (also a fixed sequence). Each step can define Glob patterns which capsules and/or namespaces should match for the step to be executed. As an example:
config:
pipeline:
steps:
- plugins:
- plugin: rigdev.sidecar
config: ...
- plugin: rigdev.datadog
config: ...
- match:
namespaces:
- some-namespace
plugins:
- plugin: rigdev.placement
config: ...
- match:
namespaces:
- some-prefix*
plugins:
- plugin: rigdev.placement
config: ...
- match:
namespaces:
- some-prefix*
names:
- my-capsule1
- my-capsule2
plugins:
- plugin: rigdev.init_container
config: ...
In this case, in instance of the rigdev.sidecar and rigdev.datadog plugin is executed for each capsule in all namespaces.
Then an instance of the rigdev.placement plugin is executed for all capsules specifically in the some-namespace namespace.
The next step also contains an instance of the rigdev.placement (possibly with a different configuration), but this is executed for all capsules in a namespace prefixed by some-prefix
.
The last step contains a rigdev.init_container plugin which is only executed for capsules named my-capsule1 or my-capsule2 in namespaces prefixed by some-prefix
.
The config
of a plugin is a single string passed to the plugin which it will interpret as its configuration. For the builtin plugins, this string is always interpreted as YAML, but it is up to the individual plugin how to parse it.
Tooling
The rig-ops
CLI contains tooling for working with plugins. To install it, see here. The plugin tooling includes
rig-ops plugins list
: Shows a list of available plugins in the operator.rig-ops plugins list-steps
: Shows the steps the operator is configured to run.rig-ops plugins check
: Shows which steps are run for which namespace/capsules. This can be nice if you have globbing logic in your pipeline config.rig-ops plugins dry-run
: Executes a dry-run of the plugin-pipeline on a given capsule, showing the output Kubernetes resources. It can use the operator configuration as is or you can supply modifications to the pipeline through flags to the command. This is nice for quick iteration on plugin configuration.
Plugin Pipeline
The Operators reconciliation of a Capsule progresses in a series of steps. First, it executes the default Capsule steps which generates the standard set of resources from a Capsule (but doesn't apply them to the cluster). Then it executes the plugins defined in the pipeline
section of the Operator config as described above. These also generate and modify the set of new resources (without applying them). After that it tries to apply the resources in a dry-run to the cluster. Only if that succeeds, does the Operator at last apply the set of new resources to the cluster.
