The Kogito Serverless Operator is built in order to help the Kogito Serverless users to build and deploy easily on Kubernetes/Knative/OpenShift a service based on Kogito that will be able to execute a workflow.
The CustomResources defined and managed by this operator are the following:
- Workflow
- Platform
- Build
You’ll need a Kubernetes cluster to run against. You can use:
to get a local cluster for testing, or run against a remote cluster.
Note: Your controller will automatically use the current context in your kubeconfig file (i.e. whatever cluster kubectl cluster-info shows).
minikube start --cpus 4 --memory 4096 --addons registry --addons metrics-server --insecure-registry "10.0.0.0/24" --insecure-registry "localhost:5000"Note: To speed up, you can increase cpus and memory options. For example, use --cpus 12 --memory 16384.
Tip: If it does work with the default driver, aka docker, you can try to start with the podman driver:
minikube start [...] --driver podmanImportant: There are some issues with the crio container runtime and Kaniko that the operator is using. Reference: GoogleContainerTools/kaniko#2201
- Install the CRDs
make install- Build and push your image to the location specified by
IMG:
make docker-build docker-push IMG=<some-registry>/<context_namespace>/kogito-serverless-operator:tag- Deploy the controller to the cluster with the image specified by
IMG:
make deploy IMG=<some-registry>/kogito-serverless-operator:tagThis will deploy the operator into the kogito-serverless-operator-system namespace.
A good starting point to check that everything is working well, it is the Greeting workflow.
- Operator is deployed on the cluster
See Getting started
Follow these steps to create a container that you can than deploy as a Service on Kubernetes or KNative.
- Create a namespace for the building phase
kubectl create namespace kogito-workflows- Create a secret for the container registry authentication
kubectl create secret docker-registry regcred --docker-server=<registry_url> --docker-username=<registry_username> --docker-password=<registry_password> --docker-email=<registry_email> -n kogito-workflowsor you directly import your local docker config into your kubernetes cluster:
kubectl create secret generic regcred --from-file=.dockerconfigjson=${HOME}/.docker/config.json --type=kubernetes.io/dockerconfigjson -n kogito-workflows- Create a Platform containing the configuration (i.e. registry address, secret) for building your workflows:
You can find a basic Platform CR example in the config folder.
kubectl apply -f config/samples/sw.kogito_v1alpha08_kogitoserverlessplatform.yaml -n kogito-workflowsNote: In this Custom Resource, spec.platform.registry.secret is the name of the secret you created just before.
Tip: You can also update "on-the-fly" the platform CR registry field with this command (change <YOUR_REGISTRY>):
cat config/samples/sw.kogito_v1alpha08_kogitoserverlessplatform.yaml | sed "s|address: .*|address: <YOUR_REGISTRY>|g" | kubectl apply -n kogito-workflows -f -- Install the Serverless Workflow custom resource:
kubectl apply -f config/samples/sw.kogito_v1alpha08_kogitoserverlessworkflow.yaml -n kogito-workflows- You can check the logs of the build of your workflow via:
kubectl logs kogito-greeting-builder -n kogito-workflowsThe final pushed image should be printed into the logs at the end of the build.
You will need to remove the different resources you created.
- Remove created workflow resources
kubectl delete -f config/samples/sw.kogito_v1alpha08_kogitoserverlessworkflow.yaml -n kogito-workflows- Remove the
kogito-workflowsnamespace
kubectl delete namespace kogito-workflows- Remove the operator
make undeployIn the development mode, a user can edit and reload the files using the quarkus dev mode. To enable the dev mode add this annotation into the KogitoServerlessWorkflow CR:
sw.kogito.kie.org/profile: dev
In development mode, different external files can be edited.
Each file type should be saved into a different configmap.
In order to be able to edit a file via a configmap, you must set up an annotation in your KogitoServerlessWorkflow CR which reference the specific configmap which is already existing into the namespace.
Then, each annotation entry will be turned into a file inside the path src/main/resources/<File type specific folder> and using the key as the filename.
See the table below for the supported types and the corresponding annotations and folder paths.
| File type | Annotation | Folder path |
|---|---|---|
| CamelRoute | sw.kogito.kie.org/resource-camel | src/main/resources/routes |
| AsyncApi | sw.kogito.kie.org/resource-openapi | src/main/resources/templates |
| OpenApi | sw.kogito.kie.org/resource-asyncapi | src/main/resources/specs |
| Generic | sw.kogito.kie.org/resource-generic | src/main/resources/generic |
You could see an example of configmap and a workflow with one of this annotation in the file
https://github.com/kiegroup/kogito-serverless-operator/tree/main/config/samples/sw.kogito_v1alpha08_kogitoserverlessworkflow_devmodeWithConfigMapAndExternalResource.yaml:
By default the builder image use a stable version aligned to the Kogito version.
In the dev mode you can override the default builder image using the devBaseImage in the KogitoServerlessPlatform:
apiVersion: sw.kogito.kie.org/v1alpha08
kind: KogitoServerlessPlatform
metadata:
name: kogito-workflow-platform
spec:
cluster: kubernetes
devBaseImage: quay.io/<your_org>/<your-swf-builder>
platform:
registry:
address: quay.io/kiegroup
secret: regcred You can find some scripts in the hack folder.
greeting_example_deploy.shwill install operator and deploy all resources in your current clustergreeting_example_remove.shwill remove the created workflow resource fromgreeting_example_deploy.shscript.
If you give the-Aor--alloption, it will also remove the operator from the cluster.
Setup a pipeline on a Openshift cluster.
Contributing is easy, just take a look at our contributors'guide.