[jira] [Comment Edited] (CAMEL-20904) camel-jbang - Run and deploy to Kubernetes
[
https://issues.apache.org/jira/browse/CAMEL-20904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860398#comment-17860398
]
Christoph Deppisch edited comment on CAMEL-20904 at 6/27/24 9:36 AM:
-
I did some experiments and the approach of a project export, then build and
deploy via SB / Quarkus standards looks promising. In my POC I have generated a
Kubernetes Manifest (kubernetes.yaml) as part of the export. The Manifest
includes all required Kubernetes resources (e.g. Deployment, Service,
ConfigMap, etc.) required to successfully run the Camel application on
Kubernetes. Usually the Manifest gets added to the project in
"{_}src/main/kubernetes{_}" folder. As soon as we have this Kubernetes Manifest
generated as part of the Camel JBang project export the standard tooling in
Quarkus and Spring Boot may take over to do the actual deployment to
Kubernetes. So we complement with what developers already are doing when
running Java apps on Kubernetes.
Also, I think the traits that Camel K operator provides can help with the
Manifest generation, too. The traits represent an easy configuration entry
point for users because they act as an abstraction layer for Kubernetes
specific configuration. The user does not necessarily need to know much about
Kubernetes details to add some configuration to the deployment (e.g. volume
mounts, env vars, etc.). The Camel K JBang plugin already makes use of the
trait config options. For instance the option in the command
{noformat}
camel k run sample.yaml --resource configmap:my-data{noformat}
results in a volume mount configuration being added to the Kubernetes
deployment container.
{noformat}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample
spec:
selector:
matchLabels:
camel.apache.org/integration: sample
template:
metadata:
labels:
camel.apache.org/integration: sample
spec:
containers:
- image: quay.io/camel/sample:1.0-SNAPSHOT
name: sample
volumeMounts:
- mountPath: /etc/camel/resources.d/_configmaps/my-data
name: my-data
readOnly: true
volumes:
- configMap:
name: my-data
name: my-data{noformat}
The trait options give us some syntactical sugar to generate the Kubernetes
Manifest and it also gives us the opportunity to establish some best practices
(e.g. how to use mount points and paths inside the Camel app container).
Usually the trait logic is applied during the Camel K operator reconciliation
loop, but we can think about also making this part of the Camel JBang tooling
to generate the Kubernetes Manifest. IMO it would be a good idea to use the
same logic on both Camel JBang and Camel K operator. There have been
discussions already in Camel K community to have Camel JBang as the single
source of truth because this is the natural entry point where developers start
to write Camel applications. Of course we need to think about how the Camel K
operator can reuse the trait logic once available in Camel JBang. The [Camel K
JBang plugin Http
agent|https://github.com/apache/camel/blob/main/dsl/camel-jbang/camel-jbang-plugin-k/src/main/java/org/apache/camel/dsl/jbang/core/commands/k/Agent.java]
that is supposed to act as a sidecar to the Camel K operator is a promising
solution for that IMO.
was (Author: christophd):
I did some experiments and the approach of a project export, then build and
deploy via SB / Quarkus standards looks promising. In my POC I have generated a
Kubernetes Manifest (kubernetes.yaml) as part of the export. The Manifest
includes all required Kubernetes resources (e.g. Deployment, Service,
ConfigMap, etc.) required to successfully run the Camel application on
Kubernetes. Usually the Manifest gets added to the project in
"{_}src/main/kubernetes{_}" folder. As soon as we have this Kubernetes Manifest
generated as part of the Camel JBang project export the standard tooling in
Quarkus and Spring Boot may take over to do the actual deployment to
Kubernetes. So we complement with what developers already are doing when
running Java apps on Kubernetes.
Also, I think the traits that Camel K operator provides can help with the
Manifest generation, too. The traits represent an easy configuration entry
point for users because they act as an abstraction layer for Kubernetes
specific configuration. The user does not necessarily need to know much about
Kubernetes details to add some configuration to the deployment (e.g. volume
mounts, env vars, etc.). The Camel K JBang plugin already makes use of the
trait config options. For instance the option in the command
{noformat}
camel k run routes.yaml --resource configmap:my-data{noformat}
results in a volume mount configuration being added to the Kubernetes
deployment container.
{noformat}
---
apiVersion: apps/v1
k
[jira] [Comment Edited] (CAMEL-20904) camel-jbang - Run and deploy to Kubernetes
[
https://issues.apache.org/jira/browse/CAMEL-20904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860398#comment-17860398
]
Christoph Deppisch edited comment on CAMEL-20904 at 6/27/24 9:36 AM:
-
I did some experiments and the approach of a project export, then build and
deploy via SB / Quarkus standards looks promising. In my POC I have generated a
Kubernetes Manifest (kubernetes.yaml) as part of the export. The Manifest
includes all required Kubernetes resources (e.g. Deployment, Service,
ConfigMap, etc.) required to successfully run the Camel application on
Kubernetes. Usually the Manifest gets added to the project in
"{_}src/main/kubernetes{_}" folder. As soon as we have this Kubernetes Manifest
generated as part of the Camel JBang project export the standard tooling in
Quarkus and Spring Boot may take over to do the actual deployment to
Kubernetes. So we complement with what developers already are doing when
running Java apps on Kubernetes.
Also, I think the traits that Camel K operator provides can help with the
Manifest generation, too. The traits represent an easy configuration entry
point for users because they act as an abstraction layer for Kubernetes
specific configuration. The user does not necessarily need to know much about
Kubernetes details to add some configuration to the deployment (e.g. volume
mounts, env vars, etc.). The Camel K JBang plugin already makes use of the
trait config options. For instance the option in the command
{noformat}
camel k run routes.yaml --resource configmap:my-data{noformat}
results in a volume mount configuration being added to the Kubernetes
deployment container.
{noformat}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample
spec:
selector:
matchLabels:
camel.apache.org/integration: sample
template:
metadata:
labels:
camel.apache.org/integration: sample
spec:
containers:
- image: quay.io/camel/sample:1.0-SNAPSHOT
name: sample
volumeMounts:
- mountPath: /etc/camel/resources.d/_configmaps/my-data
name: my-data
readOnly: true
volumes:
- configMap:
name: my-data
name: my-data{noformat}
The trait options give us some syntactical sugar to generate the Kubernetes
Manifest and it also gives us the opportunity to establish some best practices
(e.g. how to use mount points and paths inside the Camel app container).
Usually the trait logic is applied during the Camel K operator reconciliation
loop, but we can think about also making this part of the Camel JBang tooling
to generate the Kubernetes Manifest. IMO it would be a good idea to use the
same logic on both Camel JBang and Camel K operator. There have been
discussions already in Camel K community to have Camel JBang as the single
source of truth because this is the natural entry point where developers start
to write Camel applications. Of course we need to think about how the Camel K
operator can reuse the trait logic once available in Camel JBang. The [Camel K
JBang plugin Http
agent|https://github.com/apache/camel/blob/main/dsl/camel-jbang/camel-jbang-plugin-k/src/main/java/org/apache/camel/dsl/jbang/core/commands/k/Agent.java]
that is supposed to act as a sidecar to the Camel K operator is a promising
solution for that IMO.
was (Author: christophd):
I did some experiments and the approach of a project export, then build and
deploy via SB / Quarkus standards looks promising. In my POC I have generated a
Kubernetes Manifest (kubernetes.yaml) as part of the export. The Manifest
includes all required Kubernetes resources (e.g. Deployment, Service,
ConfigMap, etc.) required to successfully run the Camel application on
Kubernetes. Usually the Manifest gets added to the project in
"{_}src/main/kubernetes{_}" folder. As soon as we have this Kubernetes Manifest
generated as part of the Camel JBang project export the standard tooling in
Quarkus and Spring Boot may take over to do the actual deployment to
Kubernetes. So we complement with what developers already are doing when
running Java apps on Kubernetes.
Also, I think the traits that Camel K operator provides can help with the
Manifest generation, too. The traits represent an easy configuration entry
point for users because they act as an abstraction layer for Kubernetes
specific configuration. The user does not necessarily need to know much about
Kubernetes details to add some configuration to the deployment (e.g. volume
mounts, env vars, etc.). The Camel K JBang plugin already makes use of the
trait config options. For instance the option in the command
{noformat}
camel k run --resource configmap:my-data{noformat}
results in a volume mount configuration being added to the Kubernetes
deployment container.
{noformat}
---
apiVersion: apps/v1
kind: Deploym
[jira] [Comment Edited] (CAMEL-20904) camel-jbang - Run and deploy to Kubernetes
[ https://issues.apache.org/jira/browse/CAMEL-20904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856706#comment-17856706 ] Andrea Cosentino edited comment on CAMEL-20904 at 6/21/24 9:20 AM: --- We need to add also a parameter in the export command to manage plugins section of the POM, because both Quarkus and Spring Boot will need to add some bits to make the deploy works. Otherwise we'll have to do this behind the curtain. was (Author: ancosen): We need to add also a subcommand to manage plugins section of the POM, because both Quarkus and Spring Boot will need to add some bits to make the deploy works. > camel-jbang - Run and deploy to Kubernetes > -- > > Key: CAMEL-20904 > URL: https://issues.apache.org/jira/browse/CAMEL-20904 > Project: Camel > Issue Type: New Feature > Components: camel-jbang >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > Lets see if we can make a command to camel-jbang that can build and deploy a > standard Camel Spring Boot / Camel Quarkus (and potentially camel-main) to > kubernetes. > This would mean to export first, and then build and deploy via SB / Quarkus > standard using how you would normally do this via their maven plugins. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-20904) camel-jbang - Run and deploy to Kubernetes
[ https://issues.apache.org/jira/browse/CAMEL-20904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856706#comment-17856706 ] Andrea Cosentino edited comment on CAMEL-20904 at 6/21/24 9:17 AM: --- We need to add also a subcommand to manage plugins section of the POM, because both Quarkus and Spring Boot will need to add some bits to make the deploy works. was (Author: ancosen): We need to add also a subcommand to manage plugins section of the POM, because both Quarkus and Spring Boot will need to add some bits to make the deploy work. > camel-jbang - Run and deploy to Kubernetes > -- > > Key: CAMEL-20904 > URL: https://issues.apache.org/jira/browse/CAMEL-20904 > Project: Camel > Issue Type: New Feature > Components: camel-jbang >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > Lets see if we can make a command to camel-jbang that can build and deploy a > standard Camel Spring Boot / Camel Quarkus (and potentially camel-main) to > kubernetes. > This would mean to export first, and then build and deploy via SB / Quarkus > standard using how you would normally do this via their maven plugins. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
