diff --git a/antora.yml b/antora.yml index d826a0b6..e50fe4b4 100644 --- a/antora.yml +++ b/antora.yml @@ -8,25 +8,26 @@ asciidoc: attributes: product_name: OpenShift Serverless Logic context: OpenShift Serverless Logic - kogito_version_redhat: 1.30.0.Final-redhat-00001 + kogito_version_redhat: 1.32.0.Final-redhat-00003 quarkus_platform: com.redhat.quarkus.platform kogito_sw_ga: >- org.kie.kogito:kogito-quarkus-serverless-workflow - quarkus_version: 2.7.6.Final-redhat-00006 + quarkus_version: 2.13.5.Final-redhat-00003 java_min_version: 11+ maven_min_version: 3.8.1 graalvm_min_version: 21.3.0 spec_version: 0.8 vscode_version: 1.66.0 - kn_cli_version: 0.25.0 + kn_cli_version: 0.26.0 kie_tools_node_min_version: 16.13.2 kie_tools_pnpm_min_version: 7.0.0 kie_tools_golang_min_version: 1.19 docker_min_version: 20.10.7 docker_compose_min_version: 1.27.2 + operator_version: v1.32.0 kogito_devservices_imagename: registry.redhat.io/openshift-serverless-1-tech-preview/logic-data-index-ephemeral-rhel8:1.24.0-11 kogito_examples_repository_url: 'https://github.com/kiegroup/kogito-examples' - kogito_sw_examples_url: https://github.com/kiegroup/kogito-examples/tree/1.30.x/serverless-workflow-examples + kogito_sw_examples_url: https://github.com/kiegroup/kogito-examples/tree/1.32.x/serverless-workflow-examples kogito_examples_url: 'https://github.com/kiegroup/kogito-examples.git' kogito_apps_url: https://github.com/kiegroup/kogito-apps/tree/main quarkus_cli_url: 'https://quarkus.io/guides/cli-tooling' @@ -35,6 +36,7 @@ asciidoc: https://github.com/serverlessworkflow/specification/blob/0.8.x/specification.md cloud_events_url: 'https://cloudevents.io/' cloud_events_sdk_url: 'https://github.com/cloudevents/sdk-java' + cloud_events_git_url: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents open_api_spec_url: 'https://spec.openapis.org/oas/v3.1.0.html' quarkus_openapi_gen_url: 'https://github.com/quarkiverse/quarkus-openapi-generator' kie_tools_releases_page_url: 'https://github.com/kiegroup/kie-tools/releases' @@ -47,6 +49,7 @@ asciidoc: maven_install: 'https://maven.apache.org/install.html' docker_install: 'https://docs.docker.com/engine/install/' podman_install: 'https://docs.podman.io/en/latest/' + open_api_swagger_spec_url: https://swagger.io/docs/specification kubectl_install: 'https://kubernetes.io/docs/tasks/tools/install-kubectl' java_install_url: 'https://www.java.com/en/download/help/download_options.html' maven_install_url: 'https://maven.apache.org/install.html' @@ -66,3 +69,9 @@ asciidoc: openshift_application_data_services_service_account_url: https://console.redhat.com/application-services/service-accounts openshift_application_data_services_service_registry_url: https://console.redhat.com/application-services/service-registry openshift_application_data_services_apache_kafka_url: https://console.redhat.com/application-services/streams/kafkas + camel_url: https://camel.apache.org/ + # must align this version + camel_extensions_url: https://camel.apache.org/camel-quarkus/2.14.x/reference/extensions + kaoto_url: https://marketplace.visualstudio.com/items?itemName=redhat.vscode-kaoto + + minikube_url: https://minikube.sigs.k8s.io diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 6d142cd5..a22267b1 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -39,6 +39,7 @@ **** xref:serverless-logic:eventing/consume-produce-events-with-knative-eventing.adoc[Consuming and producing events on Knative Eventing] **** xref:serverless-logic:eventing/event-correlation-with-workflows.adoc[Event correlation in {context}] **** xref:serverless-logic:eventing/working-with-callbacks.adoc[Callback state in {context}] +**** xref:serverless-logic:eventing/working-with-openapi-callbacks.adoc[OpenAPI Callback in {context}] *** Security **** xref:serverless-logic:security/authention-support-for-openapi-services.adoc[Authentication for OpenAPI services in {context}] **** xref:serverless-logic:security/orchestrating-third-party-services-with-oauth2.adoc[Orchestration of third-party services using OAuth 2.0 authentication in {context}] @@ -51,16 +52,19 @@ //**** xref:serverless-logic:testing-and-troubleshooting/development-tools-for-troubleshooting.adoc[Development tools for troubleshooting] *** Persistence **** xref:serverless-logic:persistence/persistence-with-postgresql.adoc[Running a workflow service using PostgreSQL] +**** xref:serverless-logic:persistence/postgresql-flyway-migration.adoc[Migrate your PostgreSQL database] //**** xref:serverless-logic:persistence/workflow-database-for-db-admins.adoc[Workflows database for DB admins] // **** xref:serverless-logic:persistence/data-consistency.adoc[Data consistency] *** Cloud **** xref:serverless-logic:cloud/build-workflow-image-with-quarkus-cli.adoc[Building workflow images using Quarkus CLI] -// **** xref:serverless-logic:cloud/build-workflow-images-with-kn-cli.adoc[Building Workflow Images locally with KN CLI] // **** xref:serverless-logic:cloud/build-workflow-images-with-tekton.adoc[Building Workflow Images with Tekton Pipelines] **** xref:serverless-logic:cloud/deploying-on-minikube.adoc[Deploying your {context} application on Minikube] -// **** xref:serverless-logic:cloud/deploying-on-kubernetes-cluster.adoc[Deploying on Kubernetes Clusters] +**** xref:serverless-logic:cloud/deploying-on-kubernetes.adoc[Deploying your {context} application on Kubernetes] // **** xref:serverless-logic:cloud/versioning-workflows-in-knative.adoc[Versioning workflows in Knative] **** xref:serverless-logic:cloud/kubernetes-service-discovery.adoc[Kubernetes service discovery in {context}] +**** xref:serverless-logic:cloud/build-and-deploy-with-serverless-operator-on-kubernetes.adoc[Buiding and deploying a {context} application on Kubernetes using the {product_name} Serverless Operator] + + *** Integrations **** xref:serverless-logic:integrations/expose-metrics-to-prometheus.adoc[Exposing the workflow base metrics to Prometheus] // **** xref:serverless-logic:integrations/camel-k-integration.adoc[Integrating with Camel-K] diff --git a/modules/serverless-logic/assets/images/core/event-state-timeouts.svg b/modules/serverless-logic/assets/images/core/event-state-timeouts.svg new file mode 100644 index 00000000..dc7c5ef8 --- /dev/null +++ b/modules/serverless-logic/assets/images/core/event-state-timeouts.svg @@ -0,0 +1 @@ +StartEndPrintStartMessageWaitForEventPrintExitMessage \ No newline at end of file diff --git a/modules/serverless-logic/assets/images/core/timeout-switch-wokflow-ui.png b/modules/serverless-logic/assets/images/core/timeout-switch-wokflow-ui.png index 2ed8bdd2..e2e63cdd 100644 Binary files a/modules/serverless-logic/assets/images/core/timeout-switch-wokflow-ui.png and b/modules/serverless-logic/assets/images/core/timeout-switch-wokflow-ui.png differ diff --git a/modules/serverless-logic/assets/images/eventing/openapi-callback.png b/modules/serverless-logic/assets/images/eventing/openapi-callback.png new file mode 100644 index 00000000..72ed06d6 Binary files /dev/null and b/modules/serverless-logic/assets/images/eventing/openapi-callback.png differ diff --git a/modules/serverless-logic/pages/cloud/build-and-deploy-with-serverless-operator-on-kubernetes.adoc b/modules/serverless-logic/pages/cloud/build-and-deploy-with-serverless-operator-on-kubernetes.adoc new file mode 100644 index 00000000..02aaa3b8 --- /dev/null +++ b/modules/serverless-logic/pages/cloud/build-and-deploy-with-serverless-operator-on-kubernetes.adoc @@ -0,0 +1,200 @@ += (Community Only) = Building and deploying a {context} application on Kubernetes using the {product_name} Operator +:compat-mode!: +// Metadata: +:description: Build and deploy using the OpenShift Serverless Logic Operator a OpenShift Serverless Logic application +:keywords: kogito, workflow, serverless, operator, kubernetes, minikube, openshift +// links +:kogito_serverless_operator_url: https://github.com/kiegroup/kogito-serverless-operator/ +:kogito_greeting_example_url: https://github.com/kiegroup/kogito-examples/tree/stable/serverless-workflow-examples/serverless-workflow-greeting-quarkus +:kaniko_issue_url: https://github.com/GoogleContainerTools/kaniko/issues/2201 + +[NOTE] +==== +This feature is meant for a quick preview on community repositories, and it's not part of the developer preview. +==== +[NOTE] +==== +This feature is meant for a quick preview on community repositories, and it's not part of the developer preview. +==== + +This document describes how to build and deploy your workflow application using a Kubernetes cluster with the link:{kogito_serverless_operator_url}[{product_name} Operator]. If you don't have any cluster operational, link:{minikube_url}[Minikube] commands are given throughout the guide. + +Using the {product_name} Operator, you will be able to build and deploy a {product_name} application only by having a workflow definition. + +If you already have a container built and pushed to a container registry and you want to deploy it on the Kubernetes cluster, then you can do it without the operator following the guide xref:cloud/deploying-on-kubernetes.adoc[Deploying your {context} application on Kubernetes]. + +The link:{kogito_serverless_operator_url}[{product_name} Operator] is currently in Alpha version, is under active development and is at the moment supporting {context} definitions that are using: + +* Functions +* States + - Switch including dataConditions + - Inject including data with a transition +* Operations including Actions containing functionRef with arguments +* KeepActive +* AutoRetries +* ExpressionsLang (jq or jsonpath) + +.Prerequisites +* A workflow definition. +* A Kubernetes cluster with admin privileges. If you haven't got one prepare, you can use a local link:{minikube_url}[Minikube] instance. +* `kubectl` command-line tool is installed. Otherwise, Minikube provides it. + +== Prepare a Minikube instance + +[source,shell,subs="attributes+"] +---- +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 the build time, you can increase CPUs and memory options so that you minikube instance will have more resources. For example, use `--cpus 12 --memory 16384`. +==== + +[TIP] +==== +If it does not work with the default driver, as known as `docker`, you can try to start with the `podman` driver as follows: +==== + +.Start minikube with podman driver +[source,shell,subs="attributes+"] +---- +minikube start [...] --driver podman +---- + + +[IMPORTANT] +==== +There are some issues with the `crio` container runtime and Kaniko that the operator is using. Reference: link:{kaniko_issue_url}[ISSUE-2201] +==== + +== Setup {product_name} Operator + +In order to have an up-and-running instance of the {product_name} Operator you can use the following command: + +.Install {product_name} Operator on Kubernetes +[source,shell,subs="attributes+"] +---- +kubectl create -f https://raw.githubusercontent.com/kiegroup/kogito-serverless-operator/{operator_version}/operator.yaml +---- + +You can follow, then, the deployment of the {product_name} Operator: + +.Watch the {product_name} Operator pod +[source,shell,subs="attributes+"] +---- +kubectl get pod -n kogito-serverless-operator-system --watch +---- + +You can also follow the operator’s log: + +.Watch the {product_name} Operator pod logs +[source,shell,subs="attributes+"] +---- +kubectl logs deployment/kogito-serverless-operator-controller-manager -n kogito-serverless-operator-system -f +---- + +Once the operator is running, it will watch for new custom resources (CR) so that you can prepare your environment to be ready to build a new {context} application based on the definitions you will send to the operator. + +== Preparing for the build + +You should follow these steps to create a container that you can deploy as a service on Kubernetes. + +=== Create a namespace for the building phase + +Let's create a new namespace that will hold all the resources that we (or the operator) will create (pods, deployments, services, secretes, config map, and Custom Resources) in this guide. + +.Create a namespace for the application to build & run in +[source,bash,subs="attributes+"] +---- +kubectl create namespace kogito-workflows +---- + +=== Create a secret for the container registry authentication +.Create a secret for the container registry authentication +[source,bash,subs="attributes+"] +---- +kubectl create secret docker-registry regcred --docker-server= --docker-username= --docker-password= --docker-email= -n kogito-workflows +---- + +or you can directly import your local docker config into your Kubernetes cluster: + +.Create a secret for the container registry authentication based on local docker config +[source,bash,subs="attributes+"] +---- +kubectl create secret generic regcred --from-file=.dockerconfigjson=${HOME}/.docker/config.json --type=kubernetes.io/dockerconfigjson -n kogito-workflows +---- + +=== Create a {product_name} Platform containing the configuration (i.e. registry address, secret) for building your workflows + +The {product_name} Platform CR is the resource used to control the behavior of the {product_name} Operator. +It defines the behavior of all Custom Resources (Workflow and Build) in the given namespace. + +Since the {product_name} Operator is installed in global mode, you will need to specify a {product_name} Platform CR in each namespace where you want the operator to be executed. +You can find a basic {product_name} Serverless Platform CR example in the `config/samples` folder that you can simply apply to configure your operator. + +.Create a {product_name} Platform CR +[source,bash,subs="attributes+"] +---- +kubectl apply -f https://raw.githubusercontent.com/kiegroup/kogito-serverless-operator/{operator_version}/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 {product_name} Platform CR registry field with this command (change ) + +.Create a {product_name} Platform CR with a specific registry +[source,bash,subs="attributes+"] +---- +curl https://raw.githubusercontent.com/kiegroup/kogito-serverless-operator/{operator_version}/config/samples/sw.kogito_v1alpha08_kogitoserverlessplatform.yaml | sed "s|address: .*|address: " | kubectl apply -f - +---- + +In order to retrieve the Cluster IP address of Minikube's internal registry to configure your platform, you can use the following command: + +.Retrieve Minikube registry internal IP +[source,bash,subs="attributes+"] +---- +kubectl get svc registry -n kube-system -ojsonpath='{.spec.clusterIP}' +---- +==== + +== Build and deploy your {context} application + +You can now send your {product_name} Custom Resource to the operator which includes the {context} definition. + +You can find a basic {product_name} Platform CR example in the `config/samples` folder that you can simply apply to configure your operator. + +[source,bash,subs="attributes+"] +---- +kubectl apply -f https://raw.githubusercontent.com/kiegroup/kogito-serverless-operator/{operator_version}/config/samples/sw.kogito_v1alpha08_kogitoserverlessworkflow.yaml -n kogito-workflows +---- +You can check the logs of the build of your workflow via: + +.Get the {product_name} application pod logs +[source,bash,subs="attributes+"] +---- +kubectl logs kogito-greeting-builder -n kogito-workflows +---- + +The final pushed image must be printed into the logs at the end of the build. + +== Check the {product_name} application is running +In order to check that the {product_name} Greeting application is up and running, you can try to perform a test HTTP call, from the greeting pod. + +.Check the greeting application is running +[source,bash,subs="attributes+"] +---- +kubectl patch svc greeting -n kogito-workflows -p '{"spec": {"type": "NodePort"}}' +GREETING_SVC=$(minikube service greeting -n kogito-workflows --url) +curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"name": "John", "language": "English"}' $GREETING_SVC/greeting +---- + +If everything is working well you should receive a response like this: + +.Response from the greeting application +[source,json,subs="attributes+"] +---- +{"id":"b5fbfaa3-b125-4e6c-9311-fe5a3577efdd","workflowdata":{"name":"John","language":"English","greeting":"Hello from JSON Workflow, "}} +---- diff --git a/modules/serverless-logic/pages/cloud/build-workflow-image-with-quarkus-cli.adoc b/modules/serverless-logic/pages/cloud/build-workflow-image-with-quarkus-cli.adoc index f85da74f..4b49c060 100644 --- a/modules/serverless-logic/pages/cloud/build-workflow-image-with-quarkus-cli.adoc +++ b/modules/serverless-logic/pages/cloud/build-workflow-image-with-quarkus-cli.adoc @@ -68,7 +68,7 @@ After installing the required tooling, you can start building your workflow appl .Prerequisites * You have created a Quarkus project. * Quarkus CLI is installed. -For more information about installing the Quarkus CLI, see link:https://quarkus.io/guides/cli-tooling#installing-the-cli[Installing the Quarkus CLI]. +For more information about installing the Quarkus CLI, see link:{quarkus_cli_url}#installing-the-cli[Installing the Quarkus CLI]. .Procedure . In a command terminal, navigate to your Quarkus project. @@ -264,5 +264,7 @@ Example response:: * xref:serverless-logic:cloud/deploying-on-minikube.adoc[Deploying your {context} application on Minikube] //* xref:serverless-logic:cloud/deploying-on-kubernetes-cluster.adoc[Deploying your Serverless Workflow application on Kubernetes] Guide not available in DP1 +* xref:cloud/deploying-on-kubernetes.adoc[Deploying your {context} application on Kubernetes] + include::../../pages/_common-content/report-issue.adoc[] diff --git a/modules/serverless-logic/pages/cloud/build-workflow-images-with-kn-cli.adoc b/modules/serverless-logic/pages/cloud/build-workflow-images-with-kn-cli.adoc deleted file mode 100644 index e026ad3c..00000000 --- a/modules/serverless-logic/pages/cloud/build-workflow-images-with-kn-cli.adoc +++ /dev/null @@ -1 +0,0 @@ -//= Building Workflow Images locally with KN CLI \ No newline at end of file diff --git a/modules/serverless-logic/pages/cloud/common/_create_namespace_and_deploy_info.adoc b/modules/serverless-logic/pages/cloud/common/_create_namespace_and_deploy_info.adoc new file mode 100644 index 00000000..126954b0 --- /dev/null +++ b/modules/serverless-logic/pages/cloud/common/_create_namespace_and_deploy_info.adoc @@ -0,0 +1,40 @@ + +-- +.Create namespace +[source,shell] +---- +kubectl create namespace serverless-workflow-greeting-quarkus +---- +-- + +. Set the Kubernetes context to the newly created namespace using the following command: ++ +-- +.Set Kubernetes context to a namespace +[source,shell] +---- +kubectl config set-context --current --namespace=serverless-workflow-greeting-quarkus +---- + +After setting the context, all kubectl commands will use the selected namespace. + +You can use the following command to verify the current namespace: + +.Verify the current namespace +[source,shell] +---- +kubectl config view --minify -o jsonpath='{..namespace}' +---- +-- + +. Deploy your {context} application {deploy_application}. ++ +-- +The next step is to deploy your workflow application and execute it. +You can read the further sections on the different procedures to deploy your {context} application. + +[NOTE] +==== +You can use the native image due to the faster startup. + +For more information about installing the workflow application, see xref:cloud/build-workflow-image-with-quarkus-cli.adoc[Building workflow images using Quarkus CLI] document. +==== +-- diff --git a/modules/serverless-logic/pages/cloud/common/_deploy_workflow_application_requisites.adoc b/modules/serverless-logic/pages/cloud/common/_deploy_workflow_application_requisites.adoc new file mode 100644 index 00000000..50c3c60f --- /dev/null +++ b/modules/serverless-logic/pages/cloud/common/_deploy_workflow_application_requisites.adoc @@ -0,0 +1,8 @@ +.Prerequisites +* {cluster_kind}. +* Knative is ready. + +For more information, see {knative_procedure}. +* Knative CLI is installed. +* (Optional) Quarkus CLI is installed. + +For more information, see link:{quarkus_cli_url}[Building Quarkus Apps with Quarkus command line interface (CLI)]. +* {context} application container is ready. diff --git a/modules/serverless-logic/pages/cloud/common/_prerequisites.adoc b/modules/serverless-logic/pages/cloud/common/_prerequisites.adoc new file mode 100644 index 00000000..50c3f5d6 --- /dev/null +++ b/modules/serverless-logic/pages/cloud/common/_prerequisites.adoc @@ -0,0 +1,15 @@ +:kn_cli_url: https://knative.dev/docs/client/install-kn/ + +.Prerequisites +* Your {context} application is ready to use. + +For more information about building the application container, see xref:cloud/build-workflow-image-with-quarkus-cli.adoc[Building workflow images using Quarkus CLI]. + +* {environment_prereq} +* `kubectl` {kubectl_prereq} +* Knative CLI is installed. + +For more information, see link:{kn_cli_url}[Install the Knative CLI]. +* Knative workflow CLI is installed. + +For more information see xref:tooling/kn-plugin-workflow-overview.adoc[Serverless Workflow plug-in for Knative CLI]. +* (Optional) Quarkus CLI is installed. + +For more information, see link:{quarkus_cli_url}[Building Quarkus Apps with Quarkus command line interface (CLI)]. + diff --git a/modules/serverless-logic/pages/cloud/common/_proc_deploy_sw_kn_cli.adoc b/modules/serverless-logic/pages/cloud/common/_proc_deploy_sw_kn_cli.adoc new file mode 100644 index 00000000..c00b3aa4 --- /dev/null +++ b/modules/serverless-logic/pages/cloud/common/_proc_deploy_sw_kn_cli.adoc @@ -0,0 +1,44 @@ +[[proc-deploy-sw-application-knative-cli]] +=== Deploying your workflow application using Knative CLI + +Once you have pushed your workflow application into the {registry} registry, you can use the command-line tools, such +as Knative CLI or `kubectl` to initiate the deployment process. + +.Prerequisites +* Workflow application is installed. +* Knative CLI is installed. + +For more information, see link:{kn_cli_url}[Install the Knative CLI]. + +.Procedure +. In a command terminal, execute the following command to deploy your workflow application using Knative CLI: ++ +-- +.Example of deploying workflow application using Knative CLI +[source,shell,subs="attributes+"] +---- +kn service create hello \ + --image={k8s_registry}/serverless-workflow-greeting-quarkus:1.0 \ + --pull-policy=IfNotPresent \ + --port 8080 +---- + +.Example output +[source,shell] +---- +Creating service 'hello' in namespace 'serverless-workflow-greeting-quarkus': + + 0.066s The Route is still working to reflect the latest desired specification. + 0.099s ... + 0.322s Configuration "hello" is waiting for a Revision to become ready. + 4.885s ... + 5.061s Ingress has not yet been reconciled. + 5.322s Waiting for load balancer to be ready + 5.460s Ready to serve. + +Service 'hello' created to latest revision 'hello-00001' is available at URL: +http://hello.serverless-workflow-greeting-quarkus.10.103.94.37.sslip.io +---- +-- + +// verify deployed swf +include::_verify_if_swf_is_deployed.adoc[] diff --git a/modules/serverless-logic/pages/cloud/common/_proc_deploy_sw_kubectl.adoc b/modules/serverless-logic/pages/cloud/common/_proc_deploy_sw_kubectl.adoc new file mode 100644 index 00000000..dc639033 --- /dev/null +++ b/modules/serverless-logic/pages/cloud/common/_proc_deploy_sw_kubectl.adoc @@ -0,0 +1,141 @@ +[[proc-deploy-sw-application-kubectl]] +=== Deploying your workflow application using `kubectl` + +You can also use `kubectl` command-line interface and plain Kubernetes objects to deploy your workflow application. + +And, instead of creating `knative` `yaml|json` descriptors, you can leverage the Quarkus Kubernetes extension and +Kogito Knative add-on to generate the descriptors. + +.Prerequisites +* Workflow application ready to use. +* `kubectl` command-line tool is installed. +* (Optional) Quarkus CLI is installed + +For more information about installing the Quarkus CLI, see link:{quarkus_cli_url}#installing-the-cli[Installing the Quarkus CLI]. + +.Procedure +. Add the Quarkus extensions to generate `knative` `yaml|json` descriptors. ++ +-- +To use the Quarkus Kubernetes extension and Kogito Knative add-on, ensure that the following dependencies are available in the `pom.xml` file and Gradle: + +[tabs] +==== +pom.xml:: ++ +[source,xml] +---- + + org.kie.kogito + kogito-addons-quarkus-knative-eventing + + + io.quarkus + quarkus-kubernetes + +---- +Gradle:: ++ +[source,shell,subs="attributes+"] +---- +quarkus-kubernetes 'io.quarkus:quarkus-kubernetes:{quarkus_version}' +quarkus-kubernetes 'org.kie.kogito:kogito-addons-quarkus-knative-eventing:{page-component-version}' +---- +==== +-- + +. To generate the `knative` `yaml|json` descriptors, set the following properties in the `application.properties` +file of your workflow application: ++ +-- +.System properties to generate knative descriptors +[source,shell,subs="attributes+"] +---- +quarkus.kubernetes.deployment-target=knative +quarkus.knative.name=greeting-quarkus-kubectl +---- +-- + +. Build your workflow application. ++ +-- +Once you have built your application, you can find the generated descriptors files in the `target/kubernetes` directory: + +* `knative.json` +* `knative.yml` + +Following is an example of the generated files: + +.Knative descriptor example for a workflow application +[source,yaml,subs="attributes+"] +---- +--- +apiVersion: serving.knative.dev/v1 +kind: Service +metadata: + annotations: + app.quarkus.io/commit-id: 06c3fe8e2dfc42e2211cbcc41224f5a3d6bd1f26 + app.quarkus.io/build-timestamp: 2022-06-23 - 23:53:38 +0000 + labels: + app.kubernetes.io/name: greeting-quarkus-kubectl + name: greeting-quarkus-kubectl +spec: + template: + metadata: + labels: + app.kubernetes.io/name: greeting-quarkus-kubectl + spec: + containerConcurrency: 0 + containers: + - image: {k8s_registry}/serverless-workflow-greeting-quarkus:1.0-native + livenessProbe: + failureThreshold: 3 + httpGet: + path: /q/health/live + port: null + scheme: HTTP + initialDelaySeconds: 0 + periodSeconds: 30 + successThreshold: 1 + timeoutSeconds: 10 + name: greeting-quarkus-kubectl + ports: + - containerPort: 8080 + name: http1 + protocol: TCP + readinessProbe: + failureThreshold: 3 + httpGet: + path: /q/health/ready + port: null + scheme: HTTP + initialDelaySeconds: 0 + periodSeconds: 30 + successThreshold: 1 + timeoutSeconds: 10 +---- + +[NOTE] +==== +Once the files are generated, you might be required to add the `imagePullPolicy` manually before deploying the workflow application. +==== + +[WARNING] +==== +Some system properties are not working properly due to a bug in the `Decorate API`. For more information about the bug, see the link:https://github.com/quarkusio/quarkus/issues/23832[Quarkus issue]. + +There is a small bug on the `Decorate API` where some system properties are not taking effect, for more information take a look at this link:https://github.com/quarkusio/quarkus/issues/23832[Quarkus issue]. After the file generation, you might be required to add the `imagePullPolicy` manually before deploying it. +==== +-- + +. Enter the following command to deploy the workflow application using `kubectl`: ++ +-- +.Deploy the workflow application using `kubectl` +[source,shell] +---- +kubectl apply -f target/kubernetes/knative.yml +---- +-- + +// verify deployed swf +include::_verify_if_swf_is_deployed.adoc[] + diff --git a/modules/serverless-logic/pages/cloud/common/_verify_if_swf_is_deployed.adoc b/modules/serverless-logic/pages/cloud/common/_verify_if_swf_is_deployed.adoc new file mode 100644 index 00000000..7192d01e --- /dev/null +++ b/modules/serverless-logic/pages/cloud/common/_verify_if_swf_is_deployed.adoc @@ -0,0 +1,42 @@ +Verify if the workflow application is deployed correctly: +-- +[tabs] +==== +On kubectl:: ++ +[source,shell] +---- +kubectl get services.serving.knative.dev greeting-quarkus-cli +---- +On Knative CLI:: ++ +[source,shell] +---- +kn service list greeting-quarkus-cli +---- +==== +-- + +-- +.Example output +[source,shell] +---- +NAME URL LATEST AGE CONDITIONS READY REASON +greeting-quarkus-cli http://greeting-quarkus-cli.serverless-workflow-greeting-quarkus.10.103.94.37.sslip.io greeting-quarkus-cli-00001 7m6s 3 OK / 3 True +---- +-- + +.Use the URL in the output to send request to your workflow application. +-- +.Example request +[source,shell] +---- +curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"name": "John", "language": "English"}' http://hello.serverless-workflow-greeting-quarkus.10.103.94.37.sslip.io/jsongreet +---- + +.Example response +[source,json] +---- +{"id":"0f77abce-837e-4bd2-b4f1-a0e5e0265fcb","workflowdata":{"name":"John","language":"English","greeting":"Hello from JSON Workflow, "}} +---- +-- \ No newline at end of file diff --git a/modules/serverless-logic/pages/cloud/deploying-on-kubernetes-cluster.adoc b/modules/serverless-logic/pages/cloud/deploying-on-kubernetes-cluster.adoc deleted file mode 100644 index 478089c1..00000000 --- a/modules/serverless-logic/pages/cloud/deploying-on-kubernetes-cluster.adoc +++ /dev/null @@ -1 +0,0 @@ -//= Deploying on Kubernetes Clusters \ No newline at end of file diff --git a/modules/serverless-logic/pages/cloud/deploying-on-kubernetes.adoc b/modules/serverless-logic/pages/cloud/deploying-on-kubernetes.adoc new file mode 100644 index 00000000..c5fdcaec --- /dev/null +++ b/modules/serverless-logic/pages/cloud/deploying-on-kubernetes.adoc @@ -0,0 +1,166 @@ += Deploying your {context} application on Kubernetes +:description: Deploying Serverless Application on Kubernetes +:keywords: kogito, workflow, quarkus, serverless, kn, kubectl +:table-caption: Data Set +// envs for common content +:environment_prereq: Kubernetes Cluster is available +:kubectl_prereq: command-line tool is installed +:cluster_kind: Kubernetes with Knative is ready +:knative_procedure: <> +:deploy_application: on Kubernetes +:k8s_registry: quay.io/mynamespace +:registry: target +:container_push: Property to whether or not push images +// links +:knative_kubernetes_url: https://knative.dev/docs/install/ +:verify_knative_url: https://knative.dev/docs/serving/knative-kubernetes-services/#before-you-begin +:quay_io_url: https://quay.io/ +:k8s_pull_secret_url: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/ +:knative_domain_dns_url: https://knative.dev/docs/install/operator/knative-with-operators/#configure-dns +:quarkus_k8s_deploy_url: https://github.com/quarkusio/quarkus/issues/26385 + + +This document describes how to deploy a {context} application using a Kubernetes cluster, along with a procedure to run the Knative platform. + +// shared pre req +include::common/_prerequisites.adoc[subs=quotes+] + + +Before proceeding further, make sure that you have access to the Kubernetes cluster with Knative available. + +[[proc-verify-knative-kubernetes]] +== Verifying Knative availability on Kubernetes + +To make sure Knative is available, it can be checked with the commands below: + +.Verify if Knative is available +[source,shell] +---- +kubectl get services -n knative-serving +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +activator-service ClusterIP 10.97.110.167 9090/TCP,8008/TCP,80/TCP,81/TCP,443/TCP 44m +autoscaler ClusterIP 10.98.64.78 9090/TCP,8008/TCP,8080/TCP 44m +autoscaler-bucket-00-of-01 ClusterIP 10.111.19.134 8080/TCP 44m +controller ClusterIP 10.98.150.141 9090/TCP,8008/TCP 44m +default-domain-service ClusterIP 10.106.202.150 80/TCP 43m +domainmapping-webhook ClusterIP 10.102.87.208 9090/TCP,8008/TCP,443/TCP 44m +net-kourier-controller ClusterIP 10.100.120.208 18000/TCP 43m +webhook ClusterIP 10.108.153.180 9090/TCP,8008/TCP,443/TCP 44m +---- + +For more information on how to figure out if Knative is installed please refer to this link:{verify_knative_url}[link]. +If not, follow the installation steps described in the Knative link:{knative_kubernetes_url}[documentation]. + + +[[proc-deploy-sw-application-kubernetes]] +== Deploying your workflow application on Kubernetes + +Once Knative is ready, you can initiate the process of deploying your {context} application on Kubernetes. + + +// shared app req +include::common/_deploy_workflow_application_requisites.adoc[] + +[IMPORTANT] +==== +By default, Kubernetes does not have any registry installed. You can check with the administrator if a private registry is available. Otherwise, you can publish the Application Container image on the link:{quay_io_url}[Quay.io], or on any other registry of your preference. + +If the registry requires authentication you need to create a Pull Secret with the registry credentials, for more +information please take a look in this link:{k8s_pull_secret_url}[link]. +==== + +.Procedure +. Create `serverless-workflow-greeting-quarkus` namespace using the following command: ++ +include::common/_create_namespace_and_deploy_info.adoc[] + +In the following procedures, you can find two examples of deploying your workflow application, including: + +* <> +* <> +* <> + + +[IMPORTANT] +==== +For this tutorial, we use the `default-domain` provided by Knative that configures *Knative Serving* to use +the Magic DNS for naming resolution, for more details please check the Knative link:{knative_domain_dns_url}[documentation]. +==== + +// deploy with kn-cli +include::common/_proc_deploy_sw_kn_cli.adoc[] + +// deploy with kubectl +include::common/_proc_deploy_sw_kubectl.adoc[] + +[[proc-deploy-sw-application-quarkus-cli]] +=== Deploying your workflow application using Quarkus CLI + + +.Prerequisites +* Workflow application is installed. +* Quarkus CLI is installed. + +For more information, see link:{quarkus_cli_url}[Building Quarkus Apps with Quarkus command line interface (CLI)]. + + +.Procedure +. Add the Quarkus extensions to deploy the `knative` service ++ +-- +You can add the Kubernetes and the Kogito Knative extensions to your project with the Quarkus CLI: + +.Add kubernetes and Kogito knative extensions to the project with Quarkus CLI +[source,shell] +---- +quarkus extension add kubernetes +quarkus extension add kogito-addons-quarkus-knative-eventing +---- +-- +. To deploy your workflow application using Quarkus CLI, set the following system properties in `application.properties` file: ++ +-- +.Required system properties +[source,properties] +---- +quarkus.knative.name=greeting-quarkus-cli <1> +quarkus.kubernetes.deployment-target=knative <2> +quarkus.kubernetes.deploy=true <3> +quarkus.container-image.push=true <4> +quarkus.container-image.group=kiegroup <5> +quarkus.container-image.registry=quay.io <6> +quarkus.container-image.tag=1.0-SNAPSHOT <7> + +---- + +<1> Property to set the Knative service name +<2> Property to set the target deployment type +<3> Property to set whether or not deploy on an active Kubernetes cluster +<4> {container_push} +<5> Property to define which registry group/namespace the built image belongs to +<6> Property to define to which registry the built image will be pushed to +<7> Sets the built Container image tag + +[IMPORTANT] +==== +This feature works with Quarkus 2.10.2.Final or later. For more information, see +link:{quarkus_k8s_deploy_url}[link]. +==== +-- + +.Build and Deploy your workflow application +[source,shell] +---- +quarkus build -- -Pcontainer -DskipTests \ + -Dquarkus.container-image.push=true \ + -Dquarkus.container-image.registry=quay.io \ + -Dquarkus.container-image.group=kiegroup \ + -Dquarkus.container-image.tag=1.0-SNAPSHOT +---- + +Note that the maven profile activated is named as `container`, which provides the needed system properties to build the +target container image. + +// verify deployed swf +include::common/_verify_if_swf_is_deployed.adoc[] + +include::../../pages/_common-content/report-issue.adoc[] diff --git a/modules/serverless-logic/pages/cloud/deploying-on-minikube.adoc b/modules/serverless-logic/pages/cloud/deploying-on-minikube.adoc index 4d3bb3dd..0c724014 100644 --- a/modules/serverless-logic/pages/cloud/deploying-on-minikube.adoc +++ b/modules/serverless-logic/pages/cloud/deploying-on-minikube.adoc @@ -1,13 +1,20 @@ = Deploying your {context} application on Minikube - :compat-mode!: // Metadata: :description: Deploying Serverless Application on Minikube :keywords: kogito, workflow, quarkus, serverless, kn, kubectl, minikube :table-caption: Data Set +// envs for common content +:environment_prereq: Minikube is installed +:kubectl_prereq: command-line tool is installed. Otherwise, Minikube handles it. +:cluster_kind: Minikube is installed +:knative_procedure: <> +:deploy_application: using the Minikube registry +:k8s_registry: dev.local/kogito +:registry: Minikube's +:container_push: Property to whether or not push images. When using Minikube's remote Docker daemon to avoid image validation + // links -:minikube_url: https://minikube.sigs.k8s.io -:kn_cli_url: https://knative.dev/docs/client/install-kn/ :kn_cli_quickstart_plugin_url: https://knative.dev/docs/install/quickstart-install/#install-the-knative-cli :knative_on_minikube_step_by_step_url: https://redhat-developer-demos.github.io/knative-tutorial/knative-tutorial/setup/minikube.html :knative_issue_url: https://github.com/knative/serving/issues/6101 @@ -17,16 +24,8 @@ This document describes how to deploy your workflow application using a local Ku For more information about Minikube and related system requirements, see link:{minikube_url}/docs/start/[Getting started with Minikube] documentation. -.Prerequisites -* Your workflow application is ready to use. + -For more information about building the application container, see xref:serverless-logic:cloud/build-workflow-image-with-quarkus-cli.adoc[Building workflow images using Quarkus CLI]. - -* Minikube is installed. -* `kubectl` command-line tool is installed. Otherwise, Minikube handles it. -* Knative CLI is installed. + -For more information, see link:{kn_cli_url}[Install the Knative CLI]. -* Knative workflow CLI is installed. For more information see xref:serverless-logic:tooling/kn-plugin-workflow-overview.adoc[Serverless Workflow plug-in for Knative CLI]. -* (Optional) Quarkus CLI is installed. For more information, see link:{quarkus_cli_url}[Building Quarkus Apps with Quarkus command line interface (CLI)]. +// shared pre req +include::common/_prerequisites.adoc[] To deploy your workflow application on Minikube, you need to install Knative on Minikube. However, first you need to ensure that Minikube is installed correctly. @@ -123,13 +122,9 @@ To follow the manual process of installing Knative on Minikube, see link:{knativ Once you install Knative on Minikube, you can initiate the process of deploying your workflow application on Minikube. -.Prerequisites -* Minikube is installed. -* Knative CLI is installed. + -For more information, see <>. -* (Optional) Quarkus CLI is installed. + -For more information, see link:{quarkus_cli_url}[Building Quarkus Apps with Quarkus command line interface (CLI)]. -* {context} application container is ready. +// shared app req +include::common/_deploy_workflow_application_requisites.adoc[] + .Procedure . In a command terminal, enter the following command to configure Docker to use the in-cluster Docker daemon: @@ -203,279 +198,22 @@ Status: . After starting the Minikube tunnel, create `serverless-workflow-greeting-quarkus` namespace using the following command: + --- -.Create namespace -[source,shell] ----- -kubectl create namespace serverless-workflow-greeting-quarkus ----- --- - -. Set the context to the newly created namespace using the following command: -+ --- -.Set context to a namespace -[source,shell] ----- -kubectl config set-context --current --namespace=serverless-workflow-greeting-quarkus ----- - -After setting the context, all Minikube commands use the created namespace. You can use the following command to verify the current namespace: - -.Verify the current namespace -[source,shell] ----- -kubectl config view --minify -o jsonpath='{..namespace}' ----- --- - -. Deploy your workflow application using the Minikube registry. -+ --- -The next step is to deploy your workflow application to execute it. -You can see the further sections for different procedures to deploy your workflow application. - -[NOTE] -==== -You can use the native image due to the faster startup. + -For more information about installing the workflow application, see xref:serverless-logic:cloud/build-workflow-image-with-quarkus-cli.adoc[Building workflow images using Quarkus CLI] document. -==== --- +include::common/_create_namespace_and_deploy_info.adoc[] In the following procedures, you can find two examples of deploying your workflow application, including: -* Using Knative CLI (`kn`) -* Using `kubectl` command-line tool - -[[proc-deploy-sw-application-knative-cli]] -=== Deploying your workflow application using Knative CLI - -Once you have installed your workflow application into the Minikube registry, you can use the command-line tools, such as Knative CLI or `kubectl` to initiate the deployment process. - -.Prerequisites -* Workflow application is installed. -* Knative CLI is installed. + -For more information, see link:{kn_cli_url}[Install the Knative CLI]. - -.Procedure -. In a command terminal, execute the following command to deploy your workflow application using Knative CLI: -+ --- -.Example of deploying workflow application using Knative CLI -[source,shell] ----- -kn service create hello \ - --image=dev.local/kogito/serverless-workflow-greeting-quarkus:1.0 \ - --pull-policy=IfNotPresent \ - --port 8080 ----- - -.Example output -[source,shell] ----- -Creating service 'hello' in namespace 'serverless-workflow-greeting-quarkus': - - 0.066s The Route is still working to reflect the latest desired specification. - 0.099s ... - 0.322s Configuration "hello" is waiting for a Revision to become ready. - 4.885s ... - 5.061s Ingress has not yet been reconciled. - 5.322s Waiting for load balancer to be ready - 5.460s Ready to serve. - -Service 'hello' created to latest revision 'hello-00001' is available at URL: -http://hello.serverless-workflow-greeting-quarkus.10.103.94.37.sslip.io ----- --- - -. Use the URL in the output to send request to your workflow application. -+ --- -.Example request -[source,shell] ----- -curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"name": "John", "language": "English"}' http://hello.serverless-workflow-greeting-quarkus.10.103.94.37.sslip.io/jsongreet ----- - -.Example response -[source,json] ----- -{"id":"0f77abce-837e-4bd2-b4f1-a0e5e0265fcb","workflowdata":{"name":"John","language":"English","greeting":"Hello from JSON Workflow, "}} ----- --- - [[proc-deploy-sw-application-kubectl]] === Deploying your workflow application using `kubectl` +* <> +* <> +* <> -You can also use `kubectl` command-line interface and plain Kubernetes objects to deploy your workflow application. + -And, instead of creating `knative` `yaml|json` descriptors, you can leverage the Quarkus Kubernetes extension and Kogito Knative add-on to generate the descriptors. -.Prerequisites -* Workflow application is installed. -* `kubectl` command-line tool is installed. -* (Optional) Quarkus CLI is installed + -For more information about installing the Quarkus CLI, see link:https://quarkus.io/guides/cli-tooling#installing-the-cli[Installing the Quarkus CLI]. +// deploy with kn-cli +include::common/_proc_deploy_sw_kn_cli.adoc[] -.Procedure -. Add the Quarkus extensions to generate `knative` `yaml|json` descriptors. -+ --- -To use the Quarkus Kubernetes extension and Kogito Knative add-on, ensure that the following dependencies are available in `pom.xml` file and Gradle: - -[tabs] -==== -pom.xml:: -+ -[source,xml] ----- - - org.kie.kogito - kogito-addons-quarkus-knative-eventing - - - io.quarkus - quarkus-kubernetes - ----- -Gradle:: -+ -[source,shell,subs="attributes+"] ----- -quarkus-kubernetes 'io.quarkus:quarkus-kubernetes:{quarkus_version}' -quarkus-kubernetes 'org.kie.kogito:kogito-addons-quarkus-knative-eventing:{page-component-version}' ----- -==== --- - -. To generate the `knative` `yaml|json` descriptors, set the following properties in the `application.properties` file of your workflow application: -+ --- -.System properties to generate knative descriptors -[source,shell,subs="attributes+"] ----- -quarkus.kubernetes.deployment-target=knative -quarkus.knative.name=greeting-quarkus-kubectl ----- --- - -. Build your workflow application. -+ --- -Once you have built your application, you can find the generated descriptors files in the `target/kubernetes` directory: - -* `knative.json` -* `knative.yml` - -Following is an example of the generated files: - -.Knative descriptor example for a workflow application -[source,yaml] ----- ---- -apiVersion: serving.knative.dev/v1 -kind: Service -metadata: - annotations: - app.quarkus.io/commit-id: 06c3fe8e2dfc42e2211cbcc41224f5a3d6bd1f26 - app.quarkus.io/build-timestamp: 2022-06-23 - 23:53:38 +0000 - labels: - app.kubernetes.io/name: greeting-quarkus-kubectl - name: greeting-quarkus-kubectl -spec: - template: - metadata: - labels: - app.kubernetes.io/name: greeting-quarkus-kubectl - spec: - containerConcurrency: 0 - containers: - - image: dev.local/kogito/serverless-workflow-greeting-quarkus:1.0-native - livenessProbe: - failureThreshold: 3 - httpGet: - path: /q/health/live - port: null - scheme: HTTP - initialDelaySeconds: 0 - periodSeconds: 30 - successThreshold: 1 - timeoutSeconds: 10 - name: greeting-quarkus-kubectl - ports: - - containerPort: 8080 - name: http1 - protocol: TCP - readinessProbe: - failureThreshold: 3 - httpGet: - path: /q/health/ready - port: null - scheme: HTTP - initialDelaySeconds: 0 - periodSeconds: 30 - successThreshold: 1 - timeoutSeconds: 10 ----- - -[NOTE] -==== -Once the files are generated, you might be required to add the `imagePullPolicy` manually before deploying the workflow application. -==== - -[WARNING] -==== -Some of the system properties are not working properly due to a bug in decorate API. For more information about the bug, see link:https://github.com/quarkusio/quarkus/issues/23832[Quarkus issue]. - -There is a small bug on the 'Decorate API' where some system properties are not taking effect, for more information take a look at this link:https://github.com/quarkusio/quarkus/issues/23832[Quarkus issue]. After the file generation, you might be required to add the `imagePullPolicy` manually before deploying it. -==== --- - -. Enter the following command to deploy the workflow application using `kubectl`: -+ --- -.Deploy the workflow application using `kubectl` -[source,shell] ----- -kubectl apply -f target/kubernetes/knative.yml ----- --- - -. Verify if the workflow application is deployed correctly using the following command: -+ --- -[tabs] -==== -On kubectl:: -+ -[source,shell] ----- -kubectl get services.serving.knative.dev greeting-quarkus-kubectl ----- -On Knative CLI:: -+ -[source,shell] ----- -kn service list ----- -==== - -.Example output -[source,shell] ----- -NAME URL LATESTCREATED LATESTREADY READY REASON -greeting-quarkus-kubectl http://greeting-quarkus-kubectl.serverless-workflow-greeting-quarkus.10.103.94.37.sslip.io greeting-quarkus-kubectl-00001 greeting-quarkus-kubectl-00001 True ----- --- - -. Access the workflow application using the listed URL in the output. -+ --- -.Access workflow application -[source,shell] ----- -curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"name": "John", "language": "English"}' http://greeting-quarkus-kubectl.serverless-workflow-greeting-quarkus.10.103.94.37.sslip.io/jsongreet ----- --- +// deploy with kubectl +include::common/_proc_deploy_sw_kubectl.adoc[] [[proc-deploy-sw-application-quarkus-cli]] === Deploying your workflow application using Quarkus CLI @@ -484,7 +222,6 @@ curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d * Workflow application is installed. * Quarkus CLI is installed. + For more information, see link:{quarkus_cli_url}[Building Quarkus Apps with Quarkus command line interface (CLI)]. -* You have completed the steps in link:#proc-deploy-sw-application-kubectl[Deploying your workflow application using `kubectl`] .Procedure . Add the Quarkus extensions to deploy the `knative` service @@ -511,9 +248,10 @@ quarkus.kubernetes.deploy=true <3> quarkus.container-image.push=false <4> ---- -<1> Property for the Knative resource name -<2> Property to set whether or not deploy on an active Kubernetes cluster -<3> Property to whether or not push images when using Minikube's remove Docker daemon to avoid image validation +<1> Property to set the Knative service name +<2> Property to set the target deployment type +<3> Property to set whether or not deploy on an active Kubernetes cluster +<4> {container_push} [IMPORTANT] ==== @@ -522,41 +260,21 @@ link:{quarkus_k8s_deploy_url}[link]. ==== -- -. Verify if your workflow application is deployed correctly: -+ --- -[tabs] -==== -On kubectl:: -+ -[source,shell] ----- -kubectl get services.serving.knative.dev greeting-quarkus-cli ----- -On Knative CLI:: -+ +.Build and Deploy your workflow application [source,shell] ---- -kn service list greeting-quarkus-cli +quarkus build -- -Pcontainer -DskipTests \ + -Dquarkus.container-image.push=false \ + -Dquarkus.container-image.registry=quay.io \ + -Dquarkus.container-image.group=kiegroup \ + -Dquarkus.container-image.tag=1.0-SNAPSHOT ---- -==== -.Example output -[source,shell] ----- -NAME URL LATEST AGE CONDITIONS READY REASON -greeting-quarkus-cli http://greeting-quarkus-cli.serverless-workflow-greeting-quarkus.10.103.94.37.sslip.io greeting-quarkus-cli-00001 7m6s 3 OK / 3 True ----- --- +Note that the maven profile activated is named as `container`, which provides the needed system properties to build the +target container image. + +// verify deployed swf +include::common/_verify_if_swf_is_deployed.adoc[] -. You can access your workflow application using the listed URL in the output. -+ --- -.Access your workflow application -[source,shell] ----- -curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"name": "John", "language": "English"}' http://greeting-quarkus-cli.serverless-workflow-greeting-quarkus.10.103.94.37.sslip.io/jsongreet.37.sslip.io/jsongreet ----- --- include::../../pages/_common-content/report-issue.adoc[] diff --git a/modules/serverless-logic/pages/core/timeouts-support.adoc b/modules/serverless-logic/pages/core/timeouts-support.adoc index 3edee331..07d5f286 100644 --- a/modules/serverless-logic/pages/core/timeouts-support.adoc +++ b/modules/serverless-logic/pages/core/timeouts-support.adoc @@ -3,6 +3,9 @@ // Metadata: :description: Using timeouts in {context} :keywords: kogito, workflow, serverless, timeout, timer, expiration +// links +:jobs_service_image_url: https://quay.io/repository/kiegroup/kogito-jobs-service-allinone +:jobs_service_image_usage_url: https://github.com/kiegroup/kogito-images#jobs-services-all-in-one When you define a state in a serverless workflow, you can use the `timeouts` property to configure the maximum time to complete this state. When that time is overdue, the state is considered timed-out, and the engine continues the execution from this state. The execution flow depends on the state type, for instance, @@ -97,6 +100,80 @@ See more details about this state on the link:{spec_doc_url}#switch-date[Serverl } ---- +=== Event state timeout + +The `event` state is used to wait for one or more events to be received by the workflow and then continue the execution. +If the event state is a starting state, a new workflow instance is created. + +[NOTE] +==== +The event state is not supported as a starting state if the `exclusive` flag is set to `false`, therefore timeout is not supported in this case. +==== + +The `timeouts` property is used for this state to configure the maximum time the workflow should wait for the defined events to arrive. + +If this time is exceeded and the events are not received, the workflow moves to the state defined in the transition property or ends the workflow instance without performing any actions in case of an end state. + +You can see this in the <>. + +For more information about event state timeout, see link:{spec_doc_url}#event-timeout-definition[Serverless Workflow specification]. + +[#event-state] +.Example of event state with timeout +[source,json] +---- +{ + "name": "WaitForEvent", + "type": "event", + "onEvents": [ + { + "eventRefs": [ + "event1" + ], + "eventDataFilter": { + "data": "${ \"The event1 was received.\" }", + "toStateData": "${ .exitMessage }" + }, + "actions": [ + { + "name": "printAfterEvent1", + "functionRef": { + "refName": "systemOut", + "arguments": { + "message": "${\"event-state-timeouts: \" + $WORKFLOW.instanceId + \" executing actions for event1.\"}" + } + } + } + ] + }, + { + "eventRefs": [ + "event2" + ], + "eventDataFilter": { + "data": "${ \"The event2 was received.\" }", + "toStateData": "${ .exitMessage }" + }, + "actions": [ + { + "name": "printAfterEvent2", + "functionRef": { + "refName": "systemOut", + "arguments": { + "message": "${\"event-state-timeouts: \" + $WORKFLOW.instanceId + \" executing actions for event2.\"}" + } + } + } + ] + } + ], + "timeouts": { + "eventTimeout": "PT30S" + }, + "transition": "PrintExitMessage" +} +---- + === Deploying a timed-based workflow In order to deploy a workflow that contains timeouts or any other timer-based action, it is necessary to have Job Service running in your environment, which is an external service responsible to control the workflows timers, see the <> for more information. @@ -136,6 +213,10 @@ The example shows how to run PostgreSQL as a Kubernetes deployment, but you can ==== Ephemeral Alternatively, there is an in-memory database support that does not require any external database configuration, it can be used for testing and development purposes, but it is not recommended for production, since all jobs are lost upon a service restart or failure. +[NOTE] +==== +The job service link:{jobs_service_image_url}[image] is equipped with the PostgreSQL and Ephemeral (InMemory) options that can be switched using the `JOBS_SERVICE_PERSISTENCE`. If not set, it defaults to the `ephemeral` option. For more information about the job service, the container image can be found link:{jobs_service_image_usage_url}(here). +==== === Job Service communication [NOTE] @@ -225,6 +306,17 @@ If none of the events arrive before the timeout is overdue, the workflow then mo .Switch timeout workflow image::core/switch-state-timeouts.svg[] +=== Event workflow + +The event example is similar to the switch one but once the execution reaches the state, it waits for one of the configured events, `event1` or `event2`, to arrive, see the <>. + +If none of the configured events arrive before the timeout is overdue, the workflow execution moves to the next state defined in the corresponding `transition` property, skipping the events that were not received in time together with actions configured for them. + +If one of the events arrives before the timeout is overdue, the workflow then moves to the state defined in `transition`, executing the corresponding event that has arrived in the state definition together with actions defined for it. + +.Event timeout workflow +image::core/event-state-timeouts.svg[] + === Running the example To run the example you must have access to a kubernetes cluster running with Knative configured. @@ -369,6 +461,18 @@ curl -X 'POST' \ -d '{}' ---- +* Event + +.Creating an event workflow with timeout +[source, shell] +---- +curl -X 'POST' \ +'http://timeouts-showcase.default.10.105.86.217.sslip.io/event_state_timeouts' \ +-H 'accept: */*' \ +-H 'Content-Type: application/json' \ +-d '{}' +---- + * Checking whether the workflow instance was created .Getting the created workflow instance @@ -400,4 +504,4 @@ As you can see there are no active workflow instances, indicating the timeout wa * xref:eventing/working-with-callbacks.adoc[Callback state in {context}] -include::../../pages/_common-content/report-issue.adoc[] \ No newline at end of file +include::../../pages/_common-content/report-issue.adoc[] diff --git a/modules/serverless-logic/pages/eventing/consume-produce-events-with-knative-eventing.adoc b/modules/serverless-logic/pages/eventing/consume-produce-events-with-knative-eventing.adoc index fb2d050a..3abb8bf5 100644 --- a/modules/serverless-logic/pages/eventing/consume-produce-events-with-knative-eventing.adoc +++ b/modules/serverless-logic/pages/eventing/consume-produce-events-with-knative-eventing.adoc @@ -154,8 +154,54 @@ The following table lists the configuration property related to Knative sink gen |`default` |This property indicates the name of the default Knative broker that is deployed in the Kubernetes namespace. This broker is used as the reference to create the Knative triggers, which are responsible to delegate the events that the workflow service consumes. +| `mp.messaging.incoming.kogito_incoming_stream.path` +| `/` (root path) +|This property indicates the HTTP path where the workflow application will listen for the CloudEvents in the default incoming channel. + +| `mp.messaging.incoming..path` +| `/` (root path) +| This property indicates the HTTP path where the workflow application will listen for the CloudEvents in the specific given channel name. The channel name is the event `type` as defined in the Serverless Workflow events definition. + |=== +[[proc-manually-sending-events-to-an-http-endpoint]] +== Manually sending events to an HTTP endpoint + +You can send HTTP CloudEvents to the workflow application endpoint by using any tool that's capable to produce HTTP requests. The only requirement is that the request conforms to the link:{cloud_events_git_url}/spec.md#message[CloudEvents specification]. + +For example, with the help of `curl`, you can send an event to the workflow using the following command: + +.Sending a CloudEvent over HTTP using the structured format. +[source,shell] +---- +curl -X POST \ + -H 'Content-Type: application/cloudevents+json' \ + -d '{"datacontenttype": "application/json", "specversion":"1.0","id":"41495513-a9ef-4a81-8479-21bb14db61f0","source":"/local/curl","type":"kogito.serverless.loanbroker.aggregated.quotes.response","data": { "amount": 300000, "term": 30, "credit": { "score": 700, "history": 15 }, "quotes": [{ "bankId": "Bank1", "rate": 12.2 }, {"bankId": "Bank2", "rate": 10}] } } ' \ +http://localhost:8080 +---- + +In this example we are using the link:{cloud_events_git_url}/bindings/http-protocol-binding.md#32-structured-content-mode[CloudEvents structured format], which includes every event information within the request payload. Note the header `Content-Type` being `application/cloudevents+json`. + +Alternatively, you can use the link:{cloud_events_git_url}/bindings/http-protocol-binding.md#31-binary-content-mode[CloudEvents binary format], which includes the event metadata in the HTTP header. For example, using the same event as before: + +.Sending a CloudEvent over HTTP using the binary format. +[source,shell] +---- +curl -X POST -i \ + -H 'Content-Type: application/json' \ + -H 'ce-specversion: 1.0' \ + -H 'ce-id: 41495513-a9ef-4a81-8479-21bb14db61f0' \ + -H 'ce-source: /local/curl' \ + -H 'ce-type: kogito.serverless.loanbroker.aggregated.quotes.response' \ + -d '{ "amount": 300000, "term": 30, "credit": { "score": 700, "history": 15 }, "quotes": [{ "bankId": "Bank1", "rate": 12.2 }, {"bankId": "Bank2", "rate": 10}] }' \ +http://localhost:8080/ +---- + +You can use this tool to test your {product_name} application locally and verify if the events are being consumed correctly by the workflow. + +For more information about testing incoming and outgoing CloudEvents over HTTP, see xref:testing-and-troubleshooting/mocking-http-cloudevents-with-wiremock.adoc[Mocking HTTP CloudEvents sink using WireMock]. + + [[proc-generating-kn-objects-build-time]] == Generating Knative objects during build time diff --git a/modules/serverless-logic/pages/eventing/working-with-openapi-callbacks.adoc b/modules/serverless-logic/pages/eventing/working-with-openapi-callbacks.adoc new file mode 100644 index 00000000..b233adb9 --- /dev/null +++ b/modules/serverless-logic/pages/eventing/working-with-openapi-callbacks.adoc @@ -0,0 +1,128 @@ += OpenAPI Callback in {context} + +:compat-mode!: +// Metadata: +:description: Working with openapi callbacks +:keywords: kogito, workflow, serverless, openapi, callback, event + +This document describes the link:{open_api_spec_url}#callback-object[OpenAPI Callback] and related examples. Also, it covers the difference between OpenAPI Callback and the Serverless Workflow Callback state. The Serverless Workflow callback state can be implemented using both the OpenAPI callback and the Callback state functionalities. Both the functionalities perform an action and wait for an event to be produced as a result of the action to resume the workflow, but each of them follows a different approach in achieving it. Therefore, both OpenAPI callback and the Callback state approaches are suitable to perform _fire & wait-for-result_ operations. + +The OpenAPI callback is an asynchronous, out-of-band request that your service will send to some other service in response to specific events. In contrast, the Callback state performs an action that triggers an external activity/service which is responsible for sending a cloud event to the workflow. Both ways aim to send an event to the workflow to resume the flow. + +As mentioned in the link:{open_api_spec_url}#callback-object[OpenAPI Callback document], when the workflow makes an asynchronous service call, you must provide the callback URL in the request body. The external service invokes the callback URL and sends a link:{cloud_events_url}[CloudEvent] to the workflow. + +From a workflow perspective, asynchronous service indicates that the control is returned to the caller immediately without waiting for the action to be completed. Once the action is completed, a link:{cloud_events_url}[CloudEvent] needs to be published to resume the workflow. + +For the workflow to identify the published CloudEvent it is waiting for, the external service developer includes the workflow instance ID in the CloudEvent header or uses the xref:eventing/event-correlation-with-workflows.adoc[Event correlation]. The following figure displays the process: + +image::eventing/callbacks-explained.png[] + +The workflow correlation described in this document focuses on the former mechanism that is based on the fact that each workflow instance contains a unique identifier, which is generated automatically. + +[[ref-example-callback]] +== Example of the OpenAPI Callback + +To understand the OpenAPI Callback, see the link:{kogito_sw_examples_url}/serverless-workflow-callback-events-over-http-quarkus[`serverless-workflow-callback-events-over-http-quarkus`] example application in GitHub repository. + +This example contains a simple link:{kogito_sw_examples_url}/serverless-workflow-callback-events-over-http-quarkus/callback-workflow[workflow-service] that illustrates callback state using OpenAPI callbacks functionality. A callback is a state that invokes an action and wait for an event (event that will be eventually fired by the external service notified by the action). This example consists of a callback state that waits for an event to arrive at the wait channel. Its action calls an external service named link:{kogito_sw_examples_url}/serverless-workflow-callback-events-over-http-quarkus/callback-event-service[callback-event-service] that publishes the wait event over HTTP. After consuming the wait event, the workflow prints the message received in the wait event and ends the workflow. + +The `serverless-workflow-callback-events-over-http-quarkus` application is initiated with the following request to `http://localhost:8080/callback`: +[code,json] +---- +{ + "message": "Hello" +} +---- +Once the workflow is started, it makes an external service call with the callback URL and the workflow instance ID in the request body to link:{kogito_sw_examples_url}/serverless-workflow-callback-events-over-http-quarkus/callback-event-service[callback-event-service]. Then, as configured in the link:{kogito_sw_examples_url}/serverless-workflow-callback-events-over-http-quarkus/callback-workflow/src/main/resources/specs/callback.yaml[OpenAPI] file, the callback URL is invoked to send a CloudEvent to the workflow. + +Once the `wait` type CloudEvent is received by the callback-workflow-service, the workflow moves to the next state and ends successfully. The following figure shows the link:{kogito_sw_examples_url}/serverless-workflow-callback-events-over-http-quarkus[`serverless-workflow-callback-events-over-http-quarkus`] image: + +image::eventing/openapi-callback.png[] + +To use the OpenAPI callback in a workflow, the OpenAPI YAML file is configured with the callback as specified in the link:{kogito_sw_examples_url}/serverless-workflow-callback-events-over-http-quarkus/callback-workflow/src/main/resources/specs/callback.yaml[OpenAPI] file. + +To use the Callback state in a workflow, first CloudEvent type `wait` is declared that the workflow uses. Following is an example of CloudEvents declaration in a workflow definition: + +.Example of CloudEvent declaration in a workflow definition +[code,json] +---- + "events": [ + { + "name": "waitEvent", + "source": "", + "type": "wait" + } +---- + +After that, a Callback state is declared, which waits for a CloudEvent with the `wait` type. Following is an example of declaring a Callback state that handles the `wait` type CloudEvent: + +.Example of a Callback State declaration handling the `wait` CloudEvent +[code,json] +---- + { + "name": "waitForEvent", + "type": "callback", + "action": + { + "functionRef": { + "refName": "callBack", + "arguments": { + "uri": "http://localhost:8080/wait", + "processInstanceId": "$WORKFLOW.instanceId" + } + } + }, + "eventRef": "waitEvent", + "transition": "finish" + } +---- +[TIP] +==== +Please refer xref:service-orchestration/configuring-openapi-services-endpoints.adoc[configure openapi service endpoints] document to set the URL dynamically using an environment variable. +==== +An link:{kogito_sw_examples_url}/serverless-workflow-callback-events-over-http-quarkus/callback-event-service/src/main/java/org/kie/kogito/examples/CallbackResource.java[event listener] publishes a new `wait` type CloudEvent. Following is an example of a Java method that publishes the `wait` type CloudEvent: + +.Example of a Java method that makes a call to Callback URL and publishes the `wait` CloudEvent +[code,java] +---- + @POST + @Consumes(MediaType.APPLICATION_JSON) + public void wait(EventInput eventInput) throws JsonProcessingException { + logger.info("About to generate event for {}",eventInput); + CloudEventBuilder builder = CloudEventBuilder.v1() + .withId(UUID.randomUUID().toString()) + .withSource(URI.create("")) + .withType("wait") + .withTime(OffsetDateTime.now()) + .withExtension(CloudEventExtensionConstants.PROCESS_REFERENCE_ID, eventInput.getProcessInstanceId()) + .withData(objectMapper.writeValueAsBytes(Collections.singletonMap("message", "New Event"))); + + webClient.postAbs(eventInput.getUri()).sendJson(builder.build()).toCompletionStage(); + } +---- + +The callback-workflow-service consumes the CloudEvent, it contains an attribute named `kogitoprocrefid`, which holds the instance ID of the workflow. + +The `kogitoprocrefid` attribute is crucial because when the correlation is not used, then this attribute is the only way for the Callback state to identify that the related CloudEvent needs to be used to resume the workflow. For more information about correlation, see xref:eventing/event-correlation-with-workflows.adoc[Event correlation in {context}]. + +Note that each workflow is identified by a unique instance ID, which is automatically included in any published CloudEvent, as `kogitoprocinstanceid` CloudEvent extension. + +=== HTTP transport configuration +The `serverless-workflow-callback-events-over-http-quarkus` example application consumes the Cloudevents using Knative Eventing. For more information about incoming and outgoing CloudEvents oer HTTP, see xref:eventing/consume-produce-events-with-knative-eventing.adoc[Consuming and Producing CloudEvents over HTTP]. + +The HTTP path where the workflow application will listen for the CloudEvents in the `serverless-workflow-callback-events-over-http-quarkus` example application, is configured in the link:{kogito_sw_examples_url}/serverless-workflow-callback-events-over-http-quarkus/callback-workflow/src/main/resources/application.properties[`application.properties`] file as shown below: +[source,properties] +---- +mp.messaging.incoming.wait.connector=quarkus-http +mp.messaging.incoming.wait.path=/wait +---- + +== Additional resources + +* xref:getting-started/create-your-first-workflow-service.adoc[Creating your first workflow service] +* xref:eventing/event-correlation-with-workflows.adoc[Event correlation in {context}] +* link:{open_api_swagger_spec_url}#callbacks[OpenAPI Callback Example] + +include::../../pages/_common-content/report-issue.adoc[] + + diff --git a/modules/serverless-logic/pages/getting-started/cncf-serverless-workflow-specification-support.adoc b/modules/serverless-logic/pages/getting-started/cncf-serverless-workflow-specification-support.adoc index 61d24775..490cef2e 100644 --- a/modules/serverless-logic/pages/getting-started/cncf-serverless-workflow-specification-support.adoc +++ b/modules/serverless-logic/pages/getting-started/cncf-serverless-workflow-specification-support.adoc @@ -231,7 +231,10 @@ Alternatively, you can use xref:serverless-logic:core/understanding-workflow-err [[timeouts]] == Timeouts -{product_name} has limited support for the Timeouts feature, which covers only *Callback* and *Switch* states with events. +{product_name} has limited support for the timeouts feature, which covers only *Callback*, *Switch*, and *Event* states. + +For start event state the `exclusive` property is not supported if set to `false`, therefore the timeout is not supported for the event state when starting a workflow. + Other states will be included in future releases. For more information about timeouts, see xref:serverless-logic:core/timeouts-support.adoc[Timeouts on events for {context}]. diff --git a/modules/serverless-logic/pages/persistence/postgresql-flyway-migration.adoc b/modules/serverless-logic/pages/persistence/postgresql-flyway-migration.adoc new file mode 100644 index 00000000..c3513ce6 --- /dev/null +++ b/modules/serverless-logic/pages/persistence/postgresql-flyway-migration.adoc @@ -0,0 +1,101 @@ += Migrating Your PostgreSQL Database with a {context} upgrade +:flyway_install_url: https://flywaydb.org/download/community +:flyway_migrate_existing_url: https://flywaydb.org/documentation/learnmore/existing +:kogito_ddl_script_url: https://repo1.maven.org/maven2/org/kie/kogito/kogito-ddl +:flyway_url: https://flywaydb.org/ +:flyway_baseline_migration_url: https://documentation.red-gate.com/fd/baseline-migrations-184127465.html + +{context} provides an out-of-the-box way to manage your database schema changes with each upgrade. It uses link:{flyway_url}[Flyway] to achieve this functionality. + +When you upgrade your {context} version, by default it will pick up the latest changes available from {context} and apply them automatically. + +NOTE: This feature is currently available only for `kogito-addons-quarkus-persistence-postgresql` extension. + +== How to migrate + +=== Migrate using Flyway Config + +* {context} provides a default mechanism for migrating your database while updating the {context} version using the following `Flyway` properties (default value is `false`): ++ +-- +[source,console] +---- +quarkus.flyway.migrate-at-start=true +---- +-- +This will create a schema history table `flyway_schema_history` in your database to track the version of each database, recording in it every versioned migration file applied to build that version. + +=== Migrate using Flyway CLI +If you want to migrate manually you can use the Flyway migration CLI tool. + +* Download Flyway migration command-line tool from the link:{flyway_install_url}[Download Flyway Community Edition] website. +* Add the following properties in the `/conf/flyway.conf` file: ++ +-- +[source,console] +---- +flyway.url=jdbc:postgresql://localhost:5432/foobardb +flyway.user=foo +flyway.password=bar +---- +-- +* You can specify these options with commands as well. The Flyway CLI will prompt for the username and password if they are missing in the configuration. ++ +-- +[source,console] +---- +$ flyway migrate -url=jdbc:postgresql://localhost:5432/foobardb -user=foo -password=bar +---- +-- +* Download the {context} DDL zip from link:{kogito_ddl_script_url}[this link], choose the correct version, extract the files and use the scripts from the `postgresql` folder. +* You can specify the location of the SQL files that need to be migrated using the `flyway.locations` option. For example, ++ +-- +[source,console] +---- +flyway.locations=classpath:com.mycomp.migration,database/migrations,filesystem:/sql-migrations,s3:migrationsBucket,gcs:migrationsBucket +---- +-- + +=== Manually executing scripts +You can use the provided SQL scripts in the zip file to migrate the database by executing them one by one. + +* You can find the {context} DDL scripts by visiting link:{kogito_ddl_script_url}[this link]. +* Download the zip file of the scripts from the needed version for the {context} upgrade. +* Extract the files. +* Execute the `sql` files from `postgresql` folder. ++ +-- +[source,console] +---- +> psql -H host -U username -d database_name -a -f create_table.sql +---- +-- + +== Baseline migration +In order to apply migrations to an existing schema. It is necessary to establish the baseline from where Flyway should start executing new migrations. That means, in case your schema already contains a structure and from now on, new changes provided by {context} should be applied via Flyway integration. In Flyway terms, only migrations above `baselineVersion` will then be applied. +Using below properties you can initialize flyway schema table. + +=== Baseline using Quarkus Configuration: +-- +[source,console] +---- +quarkus.flyway.baseline-on-migrate=true +quarkus.flyway.baseline-version=1.32.0 +---- +-- +=== Baseline using Flyway CLI: +-- +[source,console] +---- +$ flyway -baselineOnMigrate="true" -baselineVersion="1.32.0" migrate +---- +-- + +NOTE: Be careful when enabling this feature as it removes the safety net which ensures that Flyway does not migrate the wrong database in case of a configuration mistake. + +=== More details on Flyway migrations +* link:{flyway_baseline_migration_url}[Baseline Migrations Documentation]. +* link:{flyway_migrate_existing_url}[Existing Database Setup Documentation]. + +include::../../pages/_common-content/report-issue.adoc[] diff --git a/modules/serverless-logic/pages/tooling/kn-plugin-workflow-overview.adoc b/modules/serverless-logic/pages/tooling/kn-plugin-workflow-overview.adoc index 49fbfac7..4fb6aa4d 100644 --- a/modules/serverless-logic/pages/tooling/kn-plugin-workflow-overview.adoc +++ b/modules/serverless-logic/pages/tooling/kn-plugin-workflow-overview.adoc @@ -20,7 +20,7 @@ This document describes how you can install and use the `kn-plugin-workflow` plu [[proc-install-sw-plugin-kn-cli]] == Installing the {context} plug-in for Knative CLI -You can use the {context} plug-in to set up your local workflow project quickly using Knative CLI. +You can use the {context} plug-in to set up your local workflow project quickly using Knative CLI. .Prerequisites * link:{java_install_url}[Java] {java_min_version} is installed. @@ -38,12 +38,12 @@ You can use the {context} plug-in to set up your local workflow project quickly * Install `kn workflow` command as a plug-in of the Knative CLI using the following steps: .. Install the Knative CLI. For installation instructions, see link:{kn_cli_install_url}[Installing kn] documentation in GitHub. .. Copy the `kn-workflow` binary to a directory in your `PATH`, such as `/usr/local/bin` and ensure that the file name is `kn-workflow`. -.. On Mac, add ownership to the root user as follows: +.. On Mac, add execution permission as follows: + `chmod +x /usr/local/bin/kn-workflow` + [WARNING] -==== +==== Some systems might block the application to run due to Apple enforcing policies. To fix this problem, check the *Security & Privacy* section in the *System Preferences* -> *General* tab to approve the application to run. For more information, see link:{apple_support_url}[Apple support article: Open a Mac app from an unidentified developer]. ==== .. Run the following command to verify that `kn-workflow` plug-in is installed successfully: @@ -132,7 +132,7 @@ kn workflow create --extension quarkus-jsonp,quarkus-smallrye-openapi You can add multiple extensions using the comma-separated names of the extensions in the previous command. [NOTE] -==== +==== When you run the `create` command for the first time, it might take a while due to the necessity of downloading the required dependencies for the Quarkus project. ==== -- @@ -140,7 +140,7 @@ When you run the `create` command for the first time, it might take a while due [[proc-build-sw-project-kn-cli]] == Building a workflow project using Knative CLI -After creating your workflow project, you can use the `build` command with `kn workflow` to build your workflow project in your current directory and to generate a container image. +After creating your workflow project, you can use the `build` command with `kn workflow` to build your workflow project in your current directory and to generate a container image. The process of building your workflow project produces a `knative.yml` file in the `./target/kubernetes` folder. If your workflow contains events, then the building process also generates a `kogito.yml` file. @@ -241,7 +241,7 @@ Before using the `--push` option, ensure that you have access to your registry. Using Docker:: + -- -The process of building your workflow project using Docker is straightforward and also a default approach. +The process of building your workflow project using Docker is straightforward and also a default approach. When using Docker, you can automatically push the container image to the respective registry by using the `--push` option as shown in the following command: diff --git a/supplemental_ui/img/favicon.ico b/supplemental_ui/img/favicon.ico new file mode 100644 index 00000000..dc51642f Binary files /dev/null and b/supplemental_ui/img/favicon.ico differ diff --git a/supplemental_ui/partials/head-meta.hbs b/supplemental_ui/partials/head-meta.hbs index f0baa60f..c067962a 100644 --- a/supplemental_ui/partials/head-meta.hbs +++ b/supplemental_ui/partials/head-meta.hbs @@ -2,6 +2,4 @@ - +