apupier commented on code in PR #1168:
URL: https://github.com/apache/camel-website/pull/1168#discussion_r1547735763
##########
content/blog/2024/04/sourceless-ck-springboot/index.md:
##########
@@ -0,0 +1,133 @@
+---
+title: "Camel K runtimes with Knative"
+date: 2024-04-02
+draft: false
+authors: [squakez]
+categories: ["Camel K", "Howtos"]
+preview: "Build an external Camel application and run Camel Springboot runtime
via Camel K as a Knative Service."
+---
+
+In the last 2.2.0 version release, Camel K added an interesting feature that
gave the users the possibility to build their Camel application externally and
run via the operator with certain limitations. In this blog we're trying to
analyze those limitations and provide some example that will show you how to
possibly leverage this feature.
+
+## What is a "sourceless" Integration?
+
+With a great effort of creativity (sarcasm), we have named this feature as
**"sourceless" Integration**. The idea is that these kind of Integrations don't
come with a source code as it happens with the regular Camel K Integrations
because they have been built externally. Everything is already bundled into a
container image. The operator cannot inspect the source code in order to
perform certain operations (mostly build-time operations), however it can still
offer its capability of deployment and monitoring. This is an example of these
Integrations:
+
+```yaml
+apiVersion: camel.apache.org/v1
+kind: Integration
+metadata:
+ annotations:
+ camel.apache.org/operator.id: camel-k
+ name: test
+spec:
+ traits:
+ container:
+ image: docker.io/my-org/my-camel-app:1.0.0
+```
+
+See more detail in the official [Camel K runtimes
documentation](/camel-k/next/running/camel-runtimes.html). The nice thing is
that with this approach you will be able to run **Camel Quarkus**, **Camel
Springboot** and **Camel Main** runtimes from Camel K operator.
+
+## How to run it
+
+A **sourceless Integration** is built by the user. The operator does not care
how this is built. What it needs to know is the final container image. Let's
see an example in action in order to show how the Camel K operator will be able
to leverage at least "deployment" traits and simplify certain operational
aspects on Kubernetes. The list of trait you can use is available in [Camel K
runtimes documentation](/camel-k/next/running/camel-runtimes.html).
+
+We will build a simple REST Camel application and we want to leverage
**Knative** in order to **scale to 0** if no traffic happens on the route.
Without the Camel K operator, you'd be needed to manage all the Knative
resources on your own. The operator will instead do all the heavy lift for you.
+
+In order to prototype the application locally we'll use **Camel JBang** and
when we're happy we'll be publishing this into the container registry used by
Camel K operator.
+
+> The entire building and publishing process can be substituted by a more
formal CICD process. For simplicity reason we're preferred the local
prototyping approach.
+
+### Create the application
+
+Let's create a Java application with a single endpoint:
+
+```java
+import org.apache.camel.builder.RouteBuilder;
+
+public class PlatformHttpServer extends RouteBuilder {
+ @Override
+ public void configure() throws Exception {
+ from("platform-http:/hello?httpMethodRestrict=GET").setBody(simple("Hello
${header.name}"));
+ }
+}
+```
+
+Thanks to Camel JBang, we can quickly run it locally and validate the
prototype:
+
+```
+camel run PlatformHttpServer.java
+```
+
+In a separate shell:
+
+```
+$ curl localhost:8080/hello --header 'name: world'
+Hello world
+```
+
+It works good enough to proceed to next step.
+
+### Publish the application
+
+Let's leverage the Camel JBang capabilities now to export the application in
our runtime of choice, say, Camel Springboot:
Review Comment:
```suggestion
Let's leverage the Camel JBang capabilities now to export the application in
our runtime of choice, say, Camel Spring Boot:
```
##########
content/blog/2024/04/sourceless-ck-springboot/index.md:
##########
@@ -0,0 +1,133 @@
+---
+title: "Camel K runtimes with Knative"
+date: 2024-04-02
+draft: false
+authors: [squakez]
+categories: ["Camel K", "Howtos"]
+preview: "Build an external Camel application and run Camel Springboot runtime
via Camel K as a Knative Service."
+---
+
+In the last 2.2.0 version release, Camel K added an interesting feature that
gave the users the possibility to build their Camel application externally and
run via the operator with certain limitations. In this blog we're trying to
analyze those limitations and provide some example that will show you how to
possibly leverage this feature.
+
+## What is a "sourceless" Integration?
+
+With a great effort of creativity (sarcasm), we have named this feature as
**"sourceless" Integration**. The idea is that these kind of Integrations don't
come with a source code as it happens with the regular Camel K Integrations
because they have been built externally. Everything is already bundled into a
container image. The operator cannot inspect the source code in order to
perform certain operations (mostly build-time operations), however it can still
offer its capability of deployment and monitoring. This is an example of these
Integrations:
+
+```yaml
+apiVersion: camel.apache.org/v1
+kind: Integration
+metadata:
+ annotations:
+ camel.apache.org/operator.id: camel-k
+ name: test
+spec:
+ traits:
+ container:
+ image: docker.io/my-org/my-camel-app:1.0.0
+```
+
+See more detail in the official [Camel K runtimes
documentation](/camel-k/next/running/camel-runtimes.html). The nice thing is
that with this approach you will be able to run **Camel Quarkus**, **Camel
Springboot** and **Camel Main** runtimes from Camel K operator.
+
+## How to run it
+
+A **sourceless Integration** is built by the user. The operator does not care
how this is built. What it needs to know is the final container image. Let's
see an example in action in order to show how the Camel K operator will be able
to leverage at least "deployment" traits and simplify certain operational
aspects on Kubernetes. The list of trait you can use is available in [Camel K
runtimes documentation](/camel-k/next/running/camel-runtimes.html).
+
+We will build a simple REST Camel application and we want to leverage
**Knative** in order to **scale to 0** if no traffic happens on the route.
Without the Camel K operator, you'd be needed to manage all the Knative
resources on your own. The operator will instead do all the heavy lift for you.
+
+In order to prototype the application locally we'll use **Camel JBang** and
when we're happy we'll be publishing this into the container registry used by
Camel K operator.
+
+> The entire building and publishing process can be substituted by a more
formal CICD process. For simplicity reason we're preferred the local
prototyping approach.
Review Comment:
```suggestion
> The entire building and publishing process can be substituted by a more
formal CICD process. For simplicity reason we preferred the local prototyping
approach.
```
##########
content/blog/2024/04/sourceless-ck-springboot/index.md:
##########
@@ -0,0 +1,133 @@
+---
+title: "Camel K runtimes with Knative"
+date: 2024-04-02
+draft: false
+authors: [squakez]
+categories: ["Camel K", "Howtos"]
+preview: "Build an external Camel application and run Camel Springboot runtime
via Camel K as a Knative Service."
+---
+
+In the last 2.2.0 version release, Camel K added an interesting feature that
gave the users the possibility to build their Camel application externally and
run via the operator with certain limitations. In this blog we're trying to
analyze those limitations and provide some example that will show you how to
possibly leverage this feature.
+
+## What is a "sourceless" Integration?
+
+With a great effort of creativity (sarcasm), we have named this feature as
**"sourceless" Integration**. The idea is that these kind of Integrations don't
come with a source code as it happens with the regular Camel K Integrations
because they have been built externally. Everything is already bundled into a
container image. The operator cannot inspect the source code in order to
perform certain operations (mostly build-time operations), however it can still
offer its capability of deployment and monitoring. This is an example of these
Integrations:
+
+```yaml
+apiVersion: camel.apache.org/v1
+kind: Integration
+metadata:
+ annotations:
+ camel.apache.org/operator.id: camel-k
+ name: test
+spec:
+ traits:
+ container:
+ image: docker.io/my-org/my-camel-app:1.0.0
+```
+
+See more detail in the official [Camel K runtimes
documentation](/camel-k/next/running/camel-runtimes.html). The nice thing is
that with this approach you will be able to run **Camel Quarkus**, **Camel
Springboot** and **Camel Main** runtimes from Camel K operator.
+
+## How to run it
+
+A **sourceless Integration** is built by the user. The operator does not care
how this is built. What it needs to know is the final container image. Let's
see an example in action in order to show how the Camel K operator will be able
to leverage at least "deployment" traits and simplify certain operational
aspects on Kubernetes. The list of trait you can use is available in [Camel K
runtimes documentation](/camel-k/next/running/camel-runtimes.html).
+
+We will build a simple REST Camel application and we want to leverage
**Knative** in order to **scale to 0** if no traffic happens on the route.
Without the Camel K operator, you'd be needed to manage all the Knative
resources on your own. The operator will instead do all the heavy lift for you.
+
+In order to prototype the application locally we'll use **Camel JBang** and
when we're happy we'll be publishing this into the container registry used by
Camel K operator.
+
+> The entire building and publishing process can be substituted by a more
formal CICD process. For simplicity reason we're preferred the local
prototyping approach.
+
+### Create the application
+
+Let's create a Java application with a single endpoint:
+
+```java
+import org.apache.camel.builder.RouteBuilder;
+
+public class PlatformHttpServer extends RouteBuilder {
+ @Override
+ public void configure() throws Exception {
+ from("platform-http:/hello?httpMethodRestrict=GET").setBody(simple("Hello
${header.name}"));
+ }
+}
+```
+
+Thanks to Camel JBang, we can quickly run it locally and validate the
prototype:
+
+```
+camel run PlatformHttpServer.java
+```
+
+In a separate shell:
+
+```
+$ curl localhost:8080/hello --header 'name: world'
+Hello world
+```
+
+It works good enough to proceed to next step.
+
+### Publish the application
+
+Let's leverage the Camel JBang capabilities now to export the application in
our runtime of choice, say, Camel Springboot:
+
+```
+$ camel export PlatformHttpServer.java --runtime spring-boot --gav
org.acme:my-csb:1.0.0 --dir csb
+```
+
+In the `csb` directory, we'll have the exported Maven project. Let's build and
run this as well. We should expect the same result, but, this time, with a
Springboot application.
Review Comment:
```suggestion
In the `csb` directory, we'll have the exported Maven project. Let's build
and run this as well. We should expect the same result, but, this time, with a
Spring Boot application.
```
##########
content/blog/2024/04/sourceless-ck-springboot/index.md:
##########
@@ -0,0 +1,133 @@
+---
+title: "Camel K runtimes with Knative"
+date: 2024-04-02
+draft: false
+authors: [squakez]
+categories: ["Camel K", "Howtos"]
+preview: "Build an external Camel application and run Camel Springboot runtime
via Camel K as a Knative Service."
Review Comment:
```suggestion
preview: "Build an external Camel application and run Camel Spring Boot
runtime via Camel K as a Knative Service."
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
