Google Git
Sign in
apache / incubator-kie-kogito-serverless-operator / refs/heads/1.38.x
commit50b04297e25f1303edc2d006774662744832d596[log] [tgz]
authorJenkins CI <noreply@redhat.com>Wed May 17 09:20:34 2023 -0400
committerJenkins CI <noreply@redhat.com>Wed May 17 09:20:34 2023 -0400
tree9ba716bb60d818783c9cfec797e38efa3384fff5
parente517d0889b71612a9c5cc66f1dd5106bd0781237 [diff]
[1.38.x] Update snapshot version to 1.38.1-snapshot

Committed by build jenkins-KIE-kogito-1.38.x-release-kogito-serverless-operator-promote-1: https://eng-jenkins-csb-business-automation.apps.ocp-c1.prod.psi.redhat.com/job/KIE/job/kogito/job/1.38.x/job/release/job/kogito-serverless-operator-promote/1/
4 files changed
tree: 9ba716bb60d818783c9cfec797e38efa3384fff5
  1. .ci/
  2. .github/
  3. api/
  4. builder/
  5. bundle/
  6. config/
  7. controllers/
  8. docs/
  9. hack/
  10. install/
  11. platform/
  12. resources/
  13. tekton/
  14. test/
  15. utils/
  16. version/
  17. .gitignore
  18. bundle.Dockerfile
  19. Dockerfile
  20. go.mod
  21. go.sum
  22. LICENSE
  23. main.go
  24. Makefile
  25. operator.yaml
  26. PROJECT
  27. README.md
  28. RELEASE_NOTES.md
README.md

Kogito Serverless Operator

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

Getting Started

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).

Prepare a Minikube instance

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 podman

Important: There are some issues with the crio container runtime and Kaniko that the operator is using. Reference: https://github.com/GoogleContainerTools/kaniko/issues/2201

Run the operator

  1. Install the CRDs
make install
  1. Build and push your image to the location specified by IMG:
make docker-build docker-push IMG=<some-registry>/kogito-serverless-operator:tag
  1. Deploy the controller to the cluster with the image specified by IMG:
make deploy IMG=<some-registry>/kogito-serverless-operator:tag

This will deploy the operator into the kogito-serverless-operator-system namespace.

Test the Greeting workflow

A good starting point to check that everything is working well, it is the Greeting workflow.

Prerequisites

Prepare for the build

Follow these steps to create a container that you can than deploy as a Service on Kubernetes or KNative.

  1. Create a namespace for the building phase
kubectl create namespace kogito-workflows
  1. 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-workflows

or 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
  1. 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-workflows

Note: 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 your workflow

  1. Install the Serverless Workflow custom resource:
kubectl apply -f config/samples/sw.kogito_v1alpha08_kogitoserverlessworkflow.yaml -n kogito-workflows
  1. You can check the logs of the build of your workflow via:
kubectl logs kogito-greeting-builder -n kogito-workflows

The final pushed image should be printed into the logs at the end of the build.

Cleanup your cluster

You will need to remove the different resources you created.

  1. Remove created workflow resources
kubectl delete -f config/samples/sw.kogito_v1alpha08_kogitoserverlessworkflow.yaml -n kogito-workflows
  1. Remove the kogito-workflows namespace
kubectl delete namespace kogito-workflows
  1. Remove the operator
make undeploy

Use Workflow Development Mode

In 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

Development mode External files

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 typeAnnotationFolder path
CamelRoutesw.kogito.kie.org/resource-camelsrc/main/resources/routes
AsyncApisw.kogito.kie.org/resource-openapisrc/main/resources/templates
OpenApisw.kogito.kie.org/resource-asyncapisrc/main/resources/specs
Genericsw.kogito.kie.org/resource-genericsrc/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:

Use Workflow Development Mode

Override Builder image and version

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

Use local scripts

You can find some scripts in the hack folder.

  • greeting_example_deploy.sh will install operator and deploy all resources in your current cluster
  • greeting_example_remove.sh will remove the created workflow resource from greeting_example_deploy.sh script.
    If you give the -A or --all option, it will also remove the operator from the cluster.

Tekton Pipeline to build and deploy the Operator

Setup a pipeline on a Openshift cluster.

Development and Contributions

Contributing is easy, just take a look at our contributors'guide.