[KOGITO-8643] Expose Workflow Dev Profile application endpoint extern… (#78)

* [KOGITO-8643] Expose Workflow Dev Profile application endpoint externally

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* [KOGITO-8643] Expose Workflow Dev Profile application endpoint externally with a Route on Openshift

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* [KOGITO-8643] Expose Workflow Dev Profile application externally with Status enricher

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Integrating suggestions coming from review

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Apply suggestions from code review

Co-authored-by: Tristan Radisson <tristan.radisson@gmail.com>
Co-authored-by: Filippe Spolti <filippespolti@gmail.com>

* Reverting pre-kustomization changes for k8s vs ocp

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Simplifying service creation in k8s

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Cleaning Makefile and README from unwanted changes

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Utils func reorganized inside profiles package

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Rabasing on main after latest update

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Apply Max's suggestions from code review

Co-authored-by: Massimiliano Dessì - (Fast Chauffeur) <desmax74@users.noreply.github.com>
Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Updating unit tests

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Updating GHA to retrieve latest commit from pr branch

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Updating GHA to retrieve latest commit from pr branch (e2e)

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Updating pod retrieving using controller-runtime client

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

* Rebasing on main

Signed-off-by: Davide Salerno <dsalerno@redhat.com>

---------

Signed-off-by: Davide Salerno <dsalerno@redhat.com>
Co-authored-by: Tristan Radisson <tristan.radisson@gmail.com>
Co-authored-by: Filippe Spolti <filippespolti@gmail.com>
Co-authored-by: Massimiliano Dessì - (Fast Chauffeur) <desmax74@users.noreply.github.com>
44 files changed
tree: ebf0f49305268c10c3ed93e79b721c447c1514c2
  1. .ci/
  2. .github/
  3. api/
  4. builder/
  5. bundle/
  6. config/
  7. controllers/
  8. hack/
  9. install/
  10. platform/
  11. resources/
  12. test/
  13. utils/
  14. version/
  15. .gitignore
  16. bundle.Dockerfile
  17. CONTRIBUTING.md
  18. Dockerfile
  19. go.mod
  20. go.sum
  21. LICENSE
  22. main.go
  23. Makefile
  24. operator.yaml
  25. PROJECT
  26. README.md
  27. 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.

Development and Contributions

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