This is the next generation of the applier which took a totaly different approach to create and update resources on kubebernetes and it is not compatible with the v1.0.1 version. Now the applier relies on the openshift/libragy.go to apply the rendered files on kubeberentes. You can fork the V1.0.1 latest version if you want to continue to improve it or switch to the V1.1.0 version.
The applier applies templated resources on kubebernetes. It can be use as a CLI or as a Go package in your code allowing you to apply embeded templates to your clusters.
The template supports the text/template framework and so you can use statements defined in that framework.
As the Mastermind/sprig is also loaded, you can use any functions defined by that framework.
By enriching the templatefunction.go, you can also develop your own functions. Check for example the function toYaml
in the templatefunction.go.
Available functions (available if WithTemplateFuncMap(applier.FuncMap())
is called while building the applier):
toYaml
which marshal a Go object to yaml.encodeBase64
which base64 encode a string, butb64enc
from sprig can be used.include
which include a template.
A Header file can be specified containing go/text block
or define
and if so will be included at the beginning of each template. This allows you to add extra business logic in your templates.
applier render --values examples/values.yaml --paths examples/simple
applier render --values examples/values.yaml --paths examples/header/templates --header examples/header/header.txt
The package provides methods to apply or render resources. These functions must be called on a Applier. An Applier can be build using the function NewApplierBuilder as follow:
applier := applierBuilder.
WithClient(kubeClient, apiExtensionsClient, dynamicClient).
Build()
There is other WithXxxx functions you can call on the applierBuilder or on the applier itself such as WithTemplateFuncMap
, WithOwner
, WithCache
, WithContext
, WithKindOrder
...
Once you have the applier you can call one of the following method.
- Apply which will call
ApplyDirectly
,ApplyCustomResources
orApplyDeployments
depending on the kind of resources. - ApplyDirectly which takes kubernetes core resources from a reader such as namespace, secret... and apply them with the provided values.
- ApplyCustomResources which takes custom resources from a reader and apply them with the provided values.
- ApplyDeployments which teakes kubernetes Deployments from a reader and apply them with the provided values.
- MustTemplateResources which takes resources from a reader and render it with the provided values.
Three readers are available:
asset.NewMemFSReader()
which allows you to read files from given directoriesasset.NewDirectoriesReader()
which allows you to read files from given directoriesasset.GetScenarioResourcesReader()
which allows you to read resources from your project. In order to use it you have to add such code in the directory you want to read:
// Copyright Red Hat
package scenario
import (
"embed"
"github.com/stolostron/applier/pkg/asset"
)
//go:embed musttemplateasset ownerref
var files embed.FS
func GetScenarioResourcesReader() *asset.ScenarioResourcesReader {
return asset.NewScenarioResourcesReader(&files)
}
and then call the GetScenarioResourcesReader() to get the reader.
Check the command line apply code to apply a list of files and this to just render command line render code.
A command-line is available to apply or render yaml files of a given directory. To generate the command line you can clone this project and then run either:
make install
to install from your local environmentmake oc-plugin
to install as aoc
pluginmake kubectl-plugin
to install as akubectl
plugin
or you can run
kubectl krew install applier
To install the krew plugin follow: krew quickstart
To get the usage, run:
[oc|kubectl] applier -h
The apply command can be use as is or with one of these 3 subcommands core-reources
, custom-resources
or deployments
. Using it directly as applier apply [options]
allows you to have a mix of core, custom and deployment resources in the --path
option. The applier will sort the resource depending on their kind before applying them.
By default, the option --sort-on-kind
is set to true and so the files will be sorted based on the kind. For example, namespace will be placed before serviceaccount.
For example you can run:
applier apply core-resources --path ./examples/simple --values ./examples/values.yaml
or
cat ./examples/values.yaml | applier apply core-resources --path ./examples/simple
The generated yaml file can be shown with option --output-file
.
Dry-run can be enabled with the option --dry-run
.
The combination of --dry-run
and --output-file /dev/stdout
(as the bellow render
command) with | kubectl apply -f -
allows to apply apply any kind of resources and not only core
, custom
and deployments
as the resources template in that case will be only rendered.
For example:
applier apply core-resources --path ./examples/simple --values ./examples/values.yaml --dry-run --output-file /dev/stdout
will not apply the resources and will display the following:
# Copyright Red Hat
apiVersion: v1
kind: Namespace
metadata:
name: "my-ns"
---
# Copyright Red Hat
apiVersion: v1
kind: ServiceAccount
metadata:
name: "my-sa"
namespace: "my-ns"
secrets:
- name: mysecret
---
The render
command is similar than using the apply
command with the options --dry-run
and --output-file /dev/stdout
applier render --path ./examples/simple --values ./examples/values.yaml
or
cat ./example/values.yaml | apply render --path ./examples/simple
The result will be:
# Copyright Red Hat
apiVersion: v1
kind: Namespace
metadata:
name: "my-ns"
---
# Copyright Red Hat
apiVersion: v1
kind: ServiceAccount
metadata:
name: "my-sa"
namespace: "my-ns"
secrets:
- name: mysecret
---
The render
subcommand can be use in conjunction with | kubectl apply -f -
to apply the generated yaml file.