You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by pc...@apache.org on 2023/03/24 08:13:13 UTC
[camel-k] 01/04: chore(doc): how to test Camel K 2.0 locally
This is an automated email from the ASF dual-hosted git repository.
pcongiusti pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel-k.git
commit 118c35836840566647160044458328a9837d69bb
Author: Pasquale Congiusti <pa...@gmail.com>
AuthorDate: Thu Mar 23 12:02:48 2023 +0100
chore(doc): how to test Camel K 2.0 locally
---
.../ROOT/pages/contributing/local-development.adoc | 75 +++++-----------------
1 file changed, 15 insertions(+), 60 deletions(-)
diff --git a/docs/modules/ROOT/pages/contributing/local-development.adoc b/docs/modules/ROOT/pages/contributing/local-development.adoc
index 82d61e8a7..ff6197b55 100644
--- a/docs/modules/ROOT/pages/contributing/local-development.adoc
+++ b/docs/modules/ROOT/pages/contributing/local-development.adoc
@@ -4,85 +4,40 @@
If you plan on contributing to Camel K, you will end up needing to run and troubleshoot your operator code locally. Here is a guideline that will help you configure your local operator running.
[[local-operator]]
-== Running operator locally
+== Running a development operator
-As soon as you build your operator locally you will ask yourself how to test it. The idea is that you execute it locally and instruct it to **watch** a namespace on a Kubernetes cluster (it may be remote or any local environment). Let's use a namespace called ``operator-test``.
+As soon as you build your operator locally you will ask yourself how to test it. In the past, we used to have the possibility to run the operator on the same development machine and connect to Kubernetes cluster. However, that approach was quite cumbersome, so now we propose a way to locally install and run your development Camel K operator as it was a "normal" installation.
-* You can start with setting the environment variable ``WATCH_NAMESPACE`` with the namespace you'd like your operator to watch. You also need to specify the name of the operator, as you may have different operators running on the cluster.
-----
-export WATCH_NAMESPACE=operator-test
-export OPERATOR_ID="camel-k-dev"
-----
+Once you have done your development, you will need to build and push Camel K Operator container image to the container registry your Kubernetes is later going to use. If you're on a local machine, you are probably using Minikube or Kind. In such case you can make your Docker daemon to use the cluster container registry. In Minikube it would be like the following:
-* The next step is to install an ``IntegrationPlatform`` on the cluster namespace. You probably need to tweak the registry parameters in order to be able to authenticate against an image repository (see below paragraph for local repository instructions). It's important to specify the target operator that will take care of this IntegrationPlatform (`-x` or `--operator-id` option).
+[source]
----
-./kamel install --skip-operator-setup -n operator-test --registry my-registry:5000 -x camel-k-dev
+eval $(minikube -p minikube docker-env)
----
-* Finally, assuming you've built your application correctly we can run the operator:
------
-./kamel operator
------
-
-* Test the local operator by creating a test `Integration`.
------
-./kamel run xyz.abc -n operator-test -x camel-k-dev
------
-
-IMPORTANT: make sure no other Camel K Operators are watching this namespace, neither you have a global Camel K Operator installed on your cluster. As you may have more than one Camel K operator installed on the cluster, it's important you specify the `-x` (or `--operator-id`) option.
+For other cluster types you may check the specific documentation. As soon as you're connected to the Docker daemon you can build images via:
-[[local-minikube]]
-== Local operator and local cluster
-
-If you want to run a local operator togheter with ``Minikube`` you will need an additional step in order to let the local operator push images in the local registry. We need to expose the local registry as described in https://minikube.sigs.k8s.io/docs/handbook/registry/#docker-on-windows[this procedure]:
-
-* Enable the addon registry (this should be already in place):
+[source]
----
-minikube addons enable registry
+make images
----
-* Get the ``Pod`` name that is in charge to run the registry and proxy the registry 5000 port to be used locally.
-----
-kubectl get pods -n kube-system
-NAME READY STATUS RESTARTS AGE
-...
-registry-fttbv 1/1 Running 40 89d
-...
+This command will build and publish your actual Camel K development version to the container registry. At this stage installing the Camel K development version will be as easy as a typical installation:
-kubectl port-forward --namespace kube-system registry-fttbv 5000:5000
+[source]
----
-
-* Update the ``IntegrationPlatform`` to instruct it to use the ``localhost`` registry:
-----
-./kamel install --skip-operator-setup -n operator-test --registry localhost:5000 --force -x camel-k-dev
+./kamel install
----
-A similar procedure may work if you use other local environments. The idea is to expose the docker registry and be able to use it from your local operator.
-
-IMPORTANT: using build strategy as `Pod` won't probably work as it will expect the registry to be available at a URL not possible to reach from a local machine.
+You can provide any customization required such as `--log-level`, `--operator-id`, etcetera. Mind that you need to use `./kamel` in order to use the development binary you've just built, as tipically, `kamel` is the production CLI you have installed in your binary path.
=== Local Camel K runtime
-Camel K integrations are based on https://github.com/apache/camel-k-runtime[Camel K runtime], generally paired with the operator release. If you need to specify a different runtime, or you have a local Camel K runtime that you want to test, then you will need to specify it in the `Integration Platform`:
-----
-./kamel install --skip-operator-setup -n operator-test --registry localhost:5000 --force --runtime-version $version -x camel-k-dev
-----
+Camel K integrations are based on https://github.com/apache/camel-k-runtime[Camel K runtime], generally paired with the operator release. If you need to specify a different runtime, or you have a local Camel K Runtime that you want to test you need to build a Camel K version bundled with the local Camel K Runtime bits
-The `$version` variable must be replaced with the version you are building. For example, `1.3.1-SNAPSHOT`. With these instructions, the operator will pick up and use the snapshot version you have released locally. In order to use the local maven repository, you will also need to edit your IntegrationPlatform as follow:
----
-$ k edit ip -n operator-test
-
-...
- spec:
- build:
- maven:
- cliOptions:
- - -V
- localRepository: /home/user/.m2/repository
- settings: {}
-...
+make images CAMEL_K_RUNTIME_DIR=<path/to/local/ck-runtime/project>
----
-pointing the `localRepository` where your local maven is storing the artifacts (it will look for the camel-k-runtime dependencies there).
+Once this is done you need to re-install via `./kamel install`.
-Alternatively, if no local registry is available, you can use another type of registry as explained in xref:installation/registry/registry.adoc[the Registry section].