From 35cd3f5a9ecabed212056dd2142f5017f20a55d0 Mon Sep 17 00:00:00 2001 From: Ricardo Zanini Date: Thu, 22 Feb 2024 14:37:06 -0300 Subject: [PATCH] Removing leftovers and fixing docs Signed-off-by: Ricardo Zanini --- .ci/jenkins/Jenkinsfile.build-image | 1 - README.md | 644 ------------------ .../features/common-custom-truststore.feature | 1 - .../features/common-dynamic-resources.feature | 2 - tests/features/common.feature | 4 - 5 files changed, 652 deletions(-) diff --git a/.ci/jenkins/Jenkinsfile.build-image b/.ci/jenkins/Jenkinsfile.build-image index b51a48cf3..892c0343b 100644 --- a/.ci/jenkins/Jenkinsfile.build-image +++ b/.ci/jenkins/Jenkinsfile.build-image @@ -181,7 +181,6 @@ pipeline { // Debug purpose in case of issue sh 'cat tests/test-apps/clone-repo.sh' sh 'cat scripts/setup-maven.sh' - sh 'cat tests/features/kogito-s2i-builder.feature' } } } diff --git a/README.md b/README.md index b44206e56..1800b4a11 100644 --- a/README.md +++ b/README.md @@ -27,29 +27,6 @@ Table of Contents - [Table of Contents](#table-of-contents) - [Kogito Images Requirements](#kogito-images-requirements) - [Kogito Images JVM Memory Management](#kogito-images-jvm-memory-management) - - [Kogito Runtime and Builder Images](#kogito-runtime-and-builder-images) - - [Kogito Builder Images](#kogito-builder-images) - - [Kogito SWF (Serverless Workflow) Builder Image usage](#kogito-swf-serverless-workflow-builder-image-usage) - - [Using as a builder](#using-as-a-builder) - - [Using for application development](#using-for-application-development) - - [Using the Kogito SWF Builder Image nightly image](#using-the-kogito-swf-builder-image-nightly-image) - - [Kogito s2i Builder Image usage](#kogito-s2i-builder-image-usage) - - [Kogito s2i Builder Image example](#kogito-s2i-builder-image-example) - - [S2i Builder Image Example with Quarkus](#s2i-builder-image-example-with-quarkus) - - [S2i Builder Image Example with Springboot](#s2i-builder-image-example-with-springboot) - - [Improving Build Time](#improving-build-time) - - [Using incremental builds](#using-incremental-builds) - - [Using a Maven mirror](#using-a-maven-mirror) - - [Kogito Runtime Images](#kogito-runtime-images) - - [Binary Builds](#binary-builds) - - [KJAR Maven Project](#kjar-maven-project) - - [Assets only](#assets-only) - - [Kogito Runtime JVM Image](#kogito-runtime-jvm-image) - - [Kogito Runtime JVM Image usage](#kogito-runtime-jvm-image-usage) - - [Kogito Runtime JVM Image examples](#kogito-runtime-jvm-image-examples) - - [Kogito Runtime Native Image](#kogito-runtime-native-image) - - [Kogito Runtime Native Image Usage](#kogito-runtime-native-image-usage) - - [Kogito Runtime Native Image Example](#kogito-runtime-native-image-example) - [Kogito Component Images](#kogito-component-images) - [Kogito Data Index Component Images](#kogito-data-index-component-images) - [Kogito Jobs Service Component Images](#kogito-jobs-service-component-images) @@ -57,9 +34,6 @@ Table of Contents - [Kogito Management Console Component Image](#kogito-management-console-component-image) - [Kogito Task Console Component Image](#kogito-task-console-component-image) - [Kogito JIT Runner Component Image](#kogito-jit-runner-component-image) - - [Using Kogito Images to Deploy Apps on OpenShift](#using-kogito-images-to-deploy-apps-on-openshift) - - [Using released images](#using-released-images) - - [Pushing the built images to a local OCP registry:](#pushing-the-built-images-to-a-local-ocp-registry) - [Contributing to Kogito Images repository](#contributing-to-kogito-images-repository) - [Building Images](#building-images) - [Image Modules](#image-modules) @@ -124,49 +98,6 @@ The build process will use 80% of the total memory reported by cgroups. For back `LIMIT_MEMORY` will be respected, but it is recommended unset it and let the memory be calculated automatic based on the available memory, it can be used in specific scenarios, like a CI test where it does not run on OpenShift cluster. - -## Kogito Runtime and Builder Images - -Today, the Kogito images are divided basically in 2 vectors, when we talk about images that would be used to assemble -or run Kogito applications: Runtime image and Builder image. -Those are described bellow. - - -### Kogito Builder Images - -The Kogito Builder Images are responsible for building the project with Apache Maven and generating the binary that will -be used by the Kogito Runtime images to run the Kogito application. - -There are three builder images available: - - -* [quay.io/kiegroup/kogito-base-builder](https://quay.io/kiegroup/kogito-base-builder) -The Kogito base Builder Image is equipped with the following components: - * OpenJDK 17.x - * Maven 3.9.3 - -* [quay.io/kiegroup/kogito-swf-builder](https://quay.io/kiegroup/kogito-swf-builder) - The Kogito SWF Builder Image extends the kogito-base-builder is equipped with the following components for faster builds: - * Quarkus dependencies - * kogito-quarkus-serverless-workflow extension dependencies - * kogito-addons-quarkus-knative-eventing extension dependencies - -* [quay.io/kiegroup/kogito-s2i-builder](https://quay.io/kiegroup/kogito-s2i-builder) - -Former name: `quay.io/kiegroup/kogito-builder` -The Kogito s2i builder image supports building applications based on Spring Boot and Quarkus. To define your runtime, specify the `RUNTIME_TYPE` environment variable. If var is not defined, it defaults to `quarkus`. -When `RUNTIME_TYPE` quarkus is chosen, the Builder Image allows you to create a native image using GraalVM, which allows you to have lightweight and fast applications ready to run in the Cloud. - -The Kogito s2i Builder Image is equipped with the following components: - - * GraalVM 23+ - * OpenJDK 17+ - * Maven 3.9.3 - -For more information about what is installed on this image, take a look [here](kogito-s2i-builder-image.yaml) in the -**modules.install** section. - - #### SonataFlow Builder Image usage ##### Using as a builder @@ -212,389 +143,6 @@ There are 2 environment variables that should not be changed when using it: That way, no new artifacts will be downloaded and you can directly use it. -#### Kogito s2i Builder Image usage - -This image contains a helper option to better understand how to use it: - -```bash -$ docker run -it quay.io/kiegroup/kogito-s2i-builder:latest /home/kogito/kogito-app-launch.sh -h -``` - -By default, quarkus is selected as runtime, and a normal java build will be performed. To perform a native build, just set the **NATIVE** build environment variable to **true**. - -See the next topic for an example. - - -#### Kogito s2i Builder Image example - -##### S2i Builder Image Example with Quarkus -In this example, let's use a simple application based on Quarkus that is available in the [Kogito Examples](https://github.com/apache/incubator-kie-kogito-examples) -repository: the *rules-quarkus-helloworld* example, with native compilation disabled. - - -```bash -$ s2i build https://github.com/apache/incubator-kie-kogito-examples.git \ - --ref main \ - -e RUNTIME_TYPE=quarkus \ - --context-dir kogito-quarkus-examples/rules-quarkus-helloworld \ - quay.io/kiegroup/kogito-s2i-builder:latest \ - rules-example:1.0 -... -[INFO] BUILD SUCCESS -[INFO] ------------------------------------------------------------------------ -[INFO] Total time: 08:37 s -[INFO] Finished at: 2020-04-06T19:13:42Z -[INFO] ------------------------------------------------------------------------ ----> Build finished, installing application from path /tmp/src ----> Installing jar file -'target/rules-quarkus-helloworld-runner.jar' -> '/home/kogito/bin/rules-quarkus-helloworld-runner.jar' ----> Copying application libraries -INFO ---> [persistence] Copying persistence files... -INFO ---> [persistence] Skip copying files, persistence directory does not exist... -Build completed successfully -``` - -After the image is built, let's test it: - -```bash -$ docker run -it -p 8080:8080 rules-example:1.0 - --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ - -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \ ---\___\_\____/_/ |_/_/|_/_/|_|\____/___/ -2020-04-08 18:59:57,753 INFO [io.quarkus] (main) rules-quarkus-helloworld 8.0.0-SNAPSHOT (powered by Quarkus 1.3.0.Final) started in 0.839s. Listening on: http://0.0.0.0:8080 -2020-04-08 18:59:57,755 INFO [io.quarkus] (main) Profile prod activated. -2020-04-08 18:59:57,756 INFO [io.quarkus] (main) Installed features: [cdi, kogito, resteasy, resteasy-jackson, resteasy-jsonb] -``` - -In a different shell, try the following command: -```bash -$ curl -H "Content-Type: application/json" -X POST -d '{"strings":["hello"]}' http://localhost:8080/hello - -# the service will return `["hello", "world"]` -``` - - - -##### S2i Builder Image Example with Springboot -In this example, let's use a simple application based on Spring Boot that is available in the [Kogito Examples](https://github.com/apache/incubator-kie-kogito-examples) -repository: the *process-springboot-example*. - -```bash -$ s2i build https://github.com/apache/incubator-kie-kogito-examples.git \ - --ref main \ - --context-dir kogito-springboot-examples/process-springboot-example \ - -e RUNTIME_TYPE=springboot \ - quay.io/kiegroup/kogito-s2i-builder:latest \ - springboot-example:1.0 -``` - -After the image is built, let's test it: - -```bash -$ docker run -it -p 8080:8080 springboot-example:1.0 -``` - -In a different shell, try the following commands: -```bash -$ curl -d '{"approver" : "john", "order" : {"orderNumber" : "12345", "shipped" : false}}' -H "Content-Type: application/json" \ - -X POST http://localhost:8080/orders - -{"id":"10de03c0-828f-4f2e-bb3f-68c3ddfea7ec","approver":"john","order":{"orderNumber":"12345","shipped":false,"total":0.4231905542160477}}✔ - -$ curl -X GET http://localhost:8080/orders -$ curl -X DELETE http://localhost:8080/orders/10de03c0-828f-4f2e-bb3f-68c3ddfea7ec -``` - -#### Improving Build Time - -The time needed to build the application is rather long. This is mainly due to maven downloading all dependencies, which takes several minutes. - - -##### Using incremental builds - -If you are planning to build many times the same application, you can use the incremental builds which will improve drastically the build time. -Let's start 2 builds with the incremental option enabled and compare the time spent to build each one: - -```bash -# First incremental build -$ time s2i build https://github.com/apache/incubator-kie-kogito-examples.git \ - --ref main \ - -e RUNTIME_TYPE=quarkus - --context-dir kogito-quarkus-examples/rules-quarkus-helloworld \ - quay.io/kiegroup/kogito-s2i-builder:latest \ - rules-example-incremental:1.0 \ - --incremental \ - --env NATIVE=false -... -real 13m49.819s -user 0m1.768s -sys 0m1.429s -``` - -And now, let's run it again. - -```bash -# Second incremental build -$ time s2i build https://github.com/apache/incubator-kie-kogito-examples.git \ - --ref main \ - -e RUNTIME_TYPE=quarkus - --context-dir kogito-quarkus-examples/rules-quarkus-helloworld \ - quay.io/kiegroup/kogito-s2i-builder:latest \ - rules-example-incremental:1.0 \ - --incremental \ - --env NATIVE=false -... -real 0m57.582s -user 0m1.628s -sys 0m1.123s -``` - -In the second try, you can see the artifacts getting unpacked and reused from the previous build. -Now, pay also attention to the time spent to build it. There is a big difference. -In fact, an incremental build reuses the previously built image and it takes advantage of already downloaded artifacts. -This can significantly improve the build time. - -##### Using a Maven mirror - -Another option is to use a Maven Mirror. -This can be used together with incremental builds to speed up the build even more. -To make it possible we just need to set the **MAVEN_MIRROR_URL** environment variable when starting a new build, see the example below: - - -```bash -# Third incremental build, with Maven mirror option -$ time s2i build https://github.com/apache/incubator-kie-kogito-examples.git \ - --ref main \ - -e RUNTIME_TYPE=quarkus - --context-dir kogito-quarkus-examples/rules-quarkus-helloworld \ - quay.io/kiegroup/kogito-s2i-builder:latest \ - rules-example-incremental-1 \ - --incremental \ - --env NATIVE=false \ - --env MAVEN_MIRROR_URL=http://nexus.apps.local.cloud/nexus/content/groups/public -... -real 0m49.658s -user 0m0.968s -sys 0m0.539s -``` - -Here you can see that the build time has again been reduced. -If the maven mirror already has all the dependencies there, the build time can be even faster. -Also, Maven generates lots of transfer logs for downloading/uploading of maven dependencies. By default, these logs are -disabled. To view these logs we need to set env variable **MAVEN_DOWNLOAD_OUTPUT** to true. - -If a custom Maven Repository is required, the S2i images also support it. -In case the **MAVEN_REPO_URL** environment variable is provided a new Repository and Plugin Repository will be added to the internal `settings.xml` file. -If no repo-id is provided using the **MAVEN_REPO_ID** environment variable, a generated one will be used. -There is also the possibility to provide more than one custom Repository. In this case, we need to provide the repo **prefix** using the **MAVEN_REPOS** environment variable. -Example, if we want to add two new repositories, the following environment variables is needed: - -```bash -MAVEN_REPOS="CENTRAL,COMPANY" -CENTRAL_MAVEN_REPO_URL="http://central.severinolabs.com/group/public" -CENTRAL_MAVEN_REPO_ID="my_cool_id_central" -COMPANY_MAVEN_REPO_URL="http://company.severinolabs.com/group/public" -COMPANY_MAVEN_REPO_ID="my_cool_id_company" -``` - -### Kogito Runtime Images - -The Kogito Runtime Images have 2 behaviors: -* Run the artifacts built by the Kogito Builder Images -* Run your pre-built local artifacts, via what we call a _Binary Build_. -For non-native built applications, they have a JRE installed to allow to execute Java applications. - -With this approach, we can have smaller and more compact images that do not include any of the build tools or artifacts (like the local maven repository for example). - -Today we have the following Kogito Runtime Images: - -* [quay.io/kiegroup/kogito-runtime-jvm](https://quay.io/kiegroup/kogito-runtime-jvm) -* [quay.io/kiegroup/kogito-runtime-native](http://quay.io/kiegroup/kogito-runtime-native) - -#### Binary Builds - -A Binary Build allows you to quickly copy the built locally artifacts into the target *Kogito Runtime Image*, -saving the time needed to build the final image using the method with Kogito Builder Images. -Below are the supported source structure: - -- KJAR Maven Project -- Assets only - -Both methods are described below. - -##### KJAR Maven Project - -[KieJAR](https://developers.redhat.com/blog/2018/03/14/what-is-a-kjar/) stands for Knowledge Is Everything jar which is a custom JAR file -that contains Business Process or Rules and all needed dependencies and files to execute it on the target runtime, -either Quarkus or Spring Boot. - -If you don't have an already existing project, the best way to create a new one is to use Kogito Maven Archetypes -to generate project structure. -The available archetypes are: - -- [Kogito Quarkus Archetype](https://github.com/apache/incubator-kie-kogito-runtimes/tree/main/archetypes/kogito-quarkus-archetype) -- [Kogito Spring Boot Archetype](https://github.com/apache/incubator-kie-kogito-runtimes/tree/main/archetypes/kogito-springboot-archetype) - -Note that, when building Quarkus based application that is **not** an *UberJAR* we also need to copy the **lib** directory -located inside the *target* directory. -Examples on how to use this feature can be found in the next topics. - - -##### Assets only - -This source structure assumes that there is no maven project but only business assets, stored either directly in the top folder -or grouped into directories. - -Types of Business assets can be: - -- Business Process definition - bpmn2 or just bpmn files -- Business Rule definition - drl files -- Business Decision definition - dmn files - -Upon build, these assets will be copied to a generated maven project and built with Maven to produce a runnable binary. Default value of group id is "com.company", artifact id is "project" and version is "1.0-SNAPSHOT". To provide custom value we need to set the **PROJECT_GROUP_ID**, **PROJECT_ARTIFACT_ID** and **PROJECT_VERSION**. - -#### Kogito Runtime JVM Image - -This Kogito Runtime Image contains only the needed files to execute a pre built Kogito application and a JRE. -The Image can run an application based on Quarkus or Springboot. Users can define `RUNTIME_TYPE` environment variable to switch between the two. - - -##### Kogito Runtime JVM Image usage - -This image contains a helper option to better understand how to use it: - -```bash -docker run -it quay.io/kiegroup/kogito-runtime-jvm:latest /home/kogito/kogito-app-launch.sh -h -``` - - -##### Kogito Runtime JVM Image examples - -In the next few lines let's take a look on how this image can be used to receive an already built UberJAR. -To configure Quarkus to generate an UberJAR please follow the instructions described [here](https://quarkus.io/guides/maven-tooling#configuration-reference) - -For this example let's use the [process-quarkus-example](https://github.com/apache/incubator-kie-kogito-examples/tree/stable/kogito-quarkus-examples/process-quarkus-example). -Once you have checked out the example on your local machine follow the steps below: - -**Example with UberJAR** -```bash -# build the example using uberjar reference -$ mvn clean package -Dquarkus.package.uber-jar -# inspect and run the generated uberjar, for instructions on how to use this example see its README file. -$ java -jar target/jbpm-quarkus-example-runner.jar - -# performing a source to image build to copy the artifacts to the runtime image -$ s2i build target/ -e RUNTIME_TYPE=quarkus quay.io/kiegroup/kogito-runtime-jvm:latest process-quarkus-example - -# run the generated image -$ docker run -p 8080:8080 -it process-quarkus-example - -# On another shell do a simple post request -curl -d '{"approver" : "john", "order" : {"orderNumber" : "12345", "shipped" : false}}' -H "Content-Type: application/json" -X POST http://localhost:8080/orders - -# notice the container logs the following message: -Order has been created Order[12345] with assigned approver JOHN -``` - - -**Example with non UberJAR** -For non uberjar the process is the same, but you only need to remove the property from Quarkus configuration to not generate uberjar. -```bash -$ mvn clean package -``` - -Note that this time there is a *lib* folder in the **target** directory. The s2i build will take care of copying it to the correct place. -Just perform a build: - -```bash -$ s2i build target/ quay.io/kiegroup/kogito-runtime-jvm:latest process-quarkus-example-non-uberjar -$ docker run -p 8080:8080 -it process-quarkus-example-non-uberjar - -# On another shell do a simple post request -$ curl -d '{"approver" : "john", "order" : {"orderNumber" : "12345", "shipped" : false}}' -H "Content-Type: application/json" -X POST http://localhost:8080/orders - -# notice the container logs the following message: -Order has been created Order[12345] with assigned approver JOHN -``` -**Runtime Image example with springboot** -Let's try, here, the *process-springboot-example*: - -```bash -$ mvn clean package -``` - -An uberjar file has been generated into the **target directory**. -Let's use this uberjar to perform the build: - -```bash -$ s2i build target/ -e RUNTIME_TYPE=springboot quay.io/kiegroup/kogito-runtime-jvm:latest spring-binary-example ------> [s2i-core] Running runtime assemble script ------> Binary build enabled, artifacts were uploaded directly to the image build ------> Cleaning up unneeded jar files -removed 'process-springboot-example-tests.jar' -removed 'process-springboot-example-sources.jar' -removed 'process-springboot-example-test-sources.jar' ------> Copying uploaded files to /home/kogito ----> Installing application binaries -'./process-springboot-example.jar' -> '/home/kogito/bin/process-springboot-example.jar' -... - -# run the output image -$ docker run -it -p 8080:8080 spring-binary-example - -# on another terminal, interact with the kogito service -$ curl -d '{"approver" : "john", "order" : {"orderNumber" : "12345", "shipped" : false}}' -H "Content-Type: application/json" -X POST http://localhost:8080/orders - -# notice the container logs the following message: -Order has been created Order[12345] with assigned approver JOHN -``` - -#### Kogito Runtime Native Image - -This Kogito Runtime Image contains only the needed files to execute a pre built Kogito application. - - -##### Kogito Runtime Native Image Usage - -This image contains a helper option to better understand how to it: - -```bash -docker run -it quay.io/kiegroup/kogito-runtime-native:latest /home/kogito/kogito-app-launch.sh -h -``` - -##### Kogito Runtime Native Image Example - -For this example, let's use the same as the previous one (process-quarkus-example). -But this time, let's perform a native build: - -```bash -$ mvn clean package -Dnative -``` - -A binary has been generated into the **target directory**. -Let's use this binary to perform the source-to-image build: - -```bash -s2i build target/ -e RUNTIME_TYPE=quarkus quay.io/kiegroup/kogito-runtime-native:latest binary-test-example ------> [s2i-core] Running runtime assemble script ------> Binary build enabled, artifacts were uploaded directly to the image build ------> Found binary file, native build. ------> Cleaning up unneeded jar files -... ----> Installing application binaries -'./process-quarkus-example-runner' -> '/home/kogito/bin/process-quarkus-example-runner' -... - -# run the output image -$ docker run -it -p 8080:8080 binary-test-example - -# on another terminal, interact with the kogito service -$ curl -d '{"approver" : "john", "order" : {"orderNumber" : "12345", "shipped" : false}}' -H "Content-Type: application/json" -X POST http://localhost:8080/orders - -# notice the container logs the following message: -Order has been created Order[12345] with assigned approver JOHN -``` - ## Kogito Component Images The Kogito Component Images can be considered as lightweight images that will complement the Kogito core engine @@ -789,199 +337,10 @@ You should notice a few debug messages being printed in the system output. You c To know what configurations this image accepts please take a look [here](kogito-jit-runner-image.yaml) on the **envs** section. -## Using Kogito Images to Deploy Apps on OpenShift - -Once the images are built and imported into a registry (quay.io or any other registry), new applications can be built and deployed within a few steps. - - -### Using released images - -As a first step, we need to make the Kogito Images available as Image Streams in OpenShift. If you have `cluster-admin` -rights you can deploy it into the **openshift** namespace, otherwise, deploy it into the namespace where you have permissions. -To install the image stream use this imagestream file: [kogito-imagestream.yaml](https://raw.githubusercontent.com/apache/incubator-kie-kogito-images/main/kogito-imagestream.yaml). -It points to the latest released version. - -Let's use the *kogito-quarkus-examples/rules-quarkus-helloworld* from [Kogito Examples](https://github.com/apache/incubator-kie-kogito-examples). - -```bash -# creating a new namespace -$ oc new-project rules-quarkus-helloworld -Now using project "rules-quarkus-helloworld" on server "https://ocp.lab.cloud:8443". - -You can add applications to this project with the 'new-app' command. For example, try: - - oc new-app centos/ruby-25-centos7~https://github.com/sclorg/ruby-ex.git - -to build a new example application in Ruby. - -# installing the imagestream on the current namespace -$ oc create -f https://raw.githubusercontent.com/apache/incubator-kie-kogito-images/0.16.0/kogito-imagestream.yaml -imagestream.image.openshift.io/kogito-runtime-native created -imagestream.image.openshift.io/kogito-runtime-jvm created -imagestream.image.openshift.io/kogito-s2i-builder created -imagestream.image.openshift.io/kogito-data-index-ephemeral created -imagestream.image.openshift.io/kogito-data-index-postgresql created -imagestream.image.openshift.io/kogito-jobs-service-ephemeral created -imagestream.image.openshift.io/kogito-jobs-service-postgresql created -imagestream.image.openshift.io/kogito-jobs-service-allinone created -imagestream.image.openshift.io/kogito-management-console created - -# performing a new build -$ oc new-build --name=rules-quarkus-helloworld-builder --image-stream=kogito-s2i-builder:latest \ - https://github.com/apache/incubator-kie-kogito-examples.git#main --context-dir=kogito-quarkus-examples/rules-quarkus-helloworld \ - --strategy=source --env NATIVE=false ---> Found image 8c9d756 (5 days old) in image stream "rules-quarkus-helloworld/kogito-s2i-builder" under tag "latest" for "kogito-s2i-builder:latest" - - Kogito based on Quarkus - ----------------------- - Platform for building Kogito based on Quarkus - - Tags: builder, kogito, quarkus - - * The source repository appears to match: jee - * A source build using source code from https://github.com/apache/incubator-kie-kogito-examples.git#main will be created - * The resulting image will be pushed to image stream tag "rules-quarkus-helloworld-builder:latest" - * Use 'start-build' to trigger a new build - ---> Creating resources with label build=drools-helloworld-builder ... - imagestreamtag.image.openshift.io "rules-quarkus-helloworld-builder:latest" created - buildconfig.build.openshift.io "rules-quarkus-helloworld-builder" created ---> Success -``` - -The build has started, you can check the logs with the following command: - -```bash -$ oc logs -f bc/rules-quarkus-helloworld-builder -``` - -Once the build is finished, you can now create a new build to copy the generated artifact from the source to image build -to the Kogito Runtime Image. To do this, execute the following command: - -```bash -$ oc new-build --name=rules-quarkus-helloworld-service --source-image=rules-quarkus-helloworld-builder \ - --source-image-path=/home/kogito/bin:. --image-stream=kogito-runtime-jvm:latest ---> Found image 1608e71 (6 days old) in image stream "rules-quarkus-helloworld/kogito-runtime-jvm" under tag "latest" for "kogito-runtime-jvm:latest" - - Kogito based on Quarkus JVM image - --------------------------------- - Runtime image for Kogito based on Quarkus JVM image - - Tags: builder, runtime, kogito, quarkus, jvm - - * A source build using will be created - * The resulting image will be pushed to image stream tag "rules-quarkus-helloworld-service:latest" - * Use 'start-build' to trigger a new build - ---> Creating resources with label build=drools-helloworld-service ... - imagestream.image.openshift.io "rules-quarkus-helloworld-service" created - buildconfig.build.openshift.io "rules-quarkus-helloworld-service" created ---> Success -``` - -Follow the logs with the following command: -```bash -$ oc logs -f bc/rules-quarkus-helloworld-service -``` - -Once the build gets finished, you need to create an application and use the service image created with the latest command. - -```bash -$ oc new-app rules-quarkus-helloworld-service:latest - --> Found image 664b295 (3 minutes old) in image stream "rules-quarkus-helloworld/rules-quarkus-helloworld-service" under tag "latest" for "rules-quarkus-helloworld-service:latest" - - temp.builder.openshift.io/rules-quarkus-helloworld/rules-quarkus-helloworld-service-1:e8062a99 - --------------------------------------------------------------------------------------- - Runtime image for Kogito based on Quarkus JVM image - - Tags: builder, runtime, kogito, quarkus, jvm - - * This image will be deployed in deployment config "rules-quarkus-helloworld-service" - * Port 8080/tcp will be load balanced by service "rules-quarkus-helloworld-service" - * Other containers can access this service through the hostname "rules-quarkus-helloworld-service" - - --> Creating resources ... - deploymentconfig.apps.openshift.io "rules-quarkus-helloworld-service" created - service "rules-quarkus-helloworld-service" created - --> Success - Application is not exposed. You can expose services to the outside world by executing one or more of the commands below: - 'oc expose svc/rules-quarkus-helloworld-service' - Run 'oc status' to view your app. -``` - -As described in the command output, to be able to access the application, we need to expose it to the external world. -For that, just execute the command listed in the output above, e.g.: - -```bash -$ oc expose svc/rules-quarkus-helloworld-service -``` - -To see the route name, just execute the following command: - -```bash -$ oc get routes -NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD -rules-quarkus-helloworld-service rules-quarkus-helloworld-service-rules-quarkus-helloworld.apps.lab.cloud rules-quarkus-helloworld-service 8080-tcp None -``` - -Now, with the service address in hand we can test our service: - -```bash -$ curl -H "Content-Type: application/json" -X POST -d '{"strings":["hello"]}' \ - http://rules-quarkus-helloworld-service-rules-quarkus-helloworld.apps.lab.cloud/hello -``` - -As output, you should see the following response: - -```json -["hello","world"] -``` - - -For more complex deployment, please use the [Kogito Cloud Operator](https://github.com/apache/incubator-kie-kogito-operator) - - - -### Pushing the built images to a local OCP registry: - -To be able to build the image it should be installed and available on OpenShift before it can be used. - -Suppose we have built the kogito-s2i-builder with the following command: - -```bash -$ make build-image image_name=kogito-s2i-builder -``` - -We'll have as output the following image: - -```bash -quay.io/kiegroup/kogito-s2i-builder:X.X.X -``` - -Then we need to tag the image properly. -Suppose your local registry is openshift.local.registry:8443, you should do: - -```bash -$ docker tag quay.io/kiegroup/kogito-s2i-builder:X.X.X \ - openshift.local.registry:8443/{NAMESPACE}/kogito-s2i-builder:X.X.X -``` - -Where the namespace is the place where you want the image to be available for usage. -Once the image is properly tagged, log in to the registry and push the new image: - -```bash -$ docker login -u -p openshift.local.registry:8443 -$ docker push openshift.local.registry:8443/{NAMESPACE}/kogito-s2i-builder:X.X.X -``` - -To deploy and test the new image, follow the same steps as described [here](#using-released-images) - - ## Contributing to Kogito Images repository Before proceeding please make sure you have checked the [requirements](#kogito-images-requirements). - ### Building Images To build the images for local testing there is a [Makefile](./Makefile) which will do all the hard work for you. @@ -1003,9 +362,6 @@ With this Makefile you can: - Build images individually, by default it will build and test each image ```bash - $ make build-image image_name=kogito-s2i-builder - $ make build-image image_name=kogito-runtime-jvm-ubi8 - $ make build-image image_name=kogito-runtime-native $ make build-image image_name=kogito-data-index-ephemeral $ make build-image image_name=kogito-data-index-postgresql $ make build-image image_name=kogito-jobs-service-ephemeral diff --git a/tests/features/common-custom-truststore.feature b/tests/features/common-custom-truststore.feature index 4184dc17c..3aca41aa7 100644 --- a/tests/features/common-custom-truststore.feature +++ b/tests/features/common-custom-truststore.feature @@ -1,4 +1,3 @@ -@quay.io/kiegroup/kogito-runtime-jvm @quay.io/kiegroup/kogito-data-index-ephemeral @quay.io/kiegroup/kogito-data-index-postgresql @quay.io/kiegroup/kogito-task-console diff --git a/tests/features/common-dynamic-resources.feature b/tests/features/common-dynamic-resources.feature index da33c0d08..ae5eb11fb 100644 --- a/tests/features/common-dynamic-resources.feature +++ b/tests/features/common-dynamic-resources.feature @@ -1,7 +1,5 @@ # Run only on images that won't die instantly # See https://github.com/apache/incubator-kie-kogito-images/issues/1722 -#@quay.io/kiegroup/kogito-s2i-builder -#@quay.io/kiegroup/kogito-runtime-jvm @quay.io/kiegroup/kogito-data-index-ephemeral #@quay.io/kiegroup/kogito-data-index-postgresql #@quay.io/kiegroup/kogito-jit-runner diff --git a/tests/features/common.feature b/tests/features/common.feature index 779232420..1f2715dbf 100644 --- a/tests/features/common.feature +++ b/tests/features/common.feature @@ -1,6 +1,3 @@ -@quay.io/kiegroup/kogito-s2i-builder -@quay.io/kiegroup/kogito-runtime-jvm -@quay.io/kiegroup/kogito-runtime-native @quay.io/kiegroup/kogito-data-index-ephemeral @quay.io/kiegroup/kogito-data-index-postgresql @quay.io/kiegroup/kogito-jit-runner @@ -9,7 +6,6 @@ @quay.io/kiegroup/kogito-management-console @quay.io/kiegroup/kogito-task-console @quay.io/kiegroup/kogito-swf-builder -@quay.io/kiegroup/kogito-base-builder Feature: Common tests for Kogito images Scenario: Verify if Kogito user is correctly configured